Who can read a MAP these days? Our new Build Analyzer is like a GPS for your embedded system!

Posted by Magnus Unemyr on Aug 26, 2016 7:56:59 AM

Second to the linker configuration file, the MAP file is probably the most obscure file embedded developers have to struggle with. In fact, I bet many embedded developers rarely study the MAP file at all – in particular the young and junior ones, or more senior developers coming from the Web, App or PC software industry. But sometimes they should, to get a clear understanding of the system and check some error-prone design issues. Linker related bugs can be very hard to find, as studying the source code will not help identifying the problem.

Our new Build Analyzer provide developers with an unprecedented view into the generated build image file, and the memory layout of different code and data sections. This novel feature presents information on memory regions and memory details in a highly visual fashion - thus providing a completely new view of your system.


Developers can use the Build Analyzer in code optimization efforts, for example to check what functions are the largest ones, and thus potentially a good target for an optimization redesign. A number of well-defined smaller functions are less error prone than a few larger ones, too. You could thus use the Build Analyzer to identify overly large functions, as they are more error-prone than smaller ones. Refactor large functions and split them into several smaller ones; and you probably get more maintainable code with less bugs as well.


The Build Analyzer can assist in speed optimization work too, where commonly executed code can be moved to faster memory areas. First, use the SWV statistical profiling function in the TrueSTUDIO Pro debugger to find out what functions execute most often. This screenshot explains how easy it is to find out what functions are called most frequently:


Then, move the most frequently executed C-functions to the fastest memory you have. This is commonly done using one of two ways:

  • On startup, copy the code from slower FLASH memory to RAM memory, which is much faster. Once the code is copied to RAM, execute it from there (the TrueSTUDIO toolchain supports this).
  • Alternatively, locate frequently executed code in on-chip memory banks instead of off-chip ones; as on-chip memory are typically much faster than external memory devices.

Using the Build Analyzer, you can then verify various code blocks are located on the expected and most optimal memory regions. The Build Analyzer can also be used to verify the location of other types of memory regions, for example when using boot loaders, interrupt vector tables, interrupt handlers, shared memory in multi-core systems, etc.

Hard-to-find bugs include incorrect memory areas being used in a bootloader scenario, interrupt vector tables starting on the wrong memory address, and interrupt handler functions being inserted at the wrong place in the interrupt vector table. The latter often causes system crashes, as a firing interrupt event causes execution to jump to a location in memory that do not contain any valid interrupt handler code.

The Build Analyzer provides a convenient view of both the LMA and VMA addresses for functions and data. LMA (Load Memory Address) is the address where the code will be loaded to by the FLASH programmer. VMA (Virtual Memory Address) is the address where the function or data is executed or accessed from at runtime.

LMA and VMA typically differs for global data and when implementing a boot loader to handle the FLASH programming (In-Application-Programming). Being able to visualize and verify the correctness of the binary helps resolving issues which may otherwise lead to run-time problems later.



Topics: Atollic TrueSTUDIO