Build results analysis : GUI to check the MAP file

A project log for STM32 BluePill Frameworks Evaluation

The STM32F103 BluePill, what's under the hoods of mbed, platformIO, Arduino,...

wassimWassim 04/30/2017 at 11:082 Comments



arm-none-eabi-size -B -d -t .\Bluepill_hello.elf
   text    data     bss     dec     hex filename
  55240    2496     872   58608    e4f0 .\Bluepill_hello.elf
  55240    2496     872   58608    e4f0 (TOTALS)

Yes, but that does not help, well the next level of details is to look into the map file,

LD_FLAGS :=-Wl, -Wl,--gc-sections -Wl,--wrap,main -Wl,--wrap,exit -Wl,--wrap,atexit -mcpu=cortex-m3 -mthumb

I just had to drag and drop the map file, it complies with the "intuitive" qualification, and also with the "flexibility" as it works with command lines. It shows all results of size by Module, by file, by section.

It is also possible to sort by size:



Kiril Zyapkov wrote 04/05/2018 at 06:56 point

Did you figure this out? I'm digging into compiler and linker flags, it seems `mbed` wraps some memory management functions and links *a lot* more files ...

  Are you sure? yes | no

Wassim wrote 04/05/2018 at 17:48 point

If you're interested into reducing the size, I obtained max reductions with -Os and nano.specs, see this develop_nano.json from my repo :

It is true that mbed as an os is wrapping a lot all of the functions, I did not look into the memory management, but the pwm for example, was a tleast x1000 times slower than it could be.

here the default mbed pwm functions example

and here direct registers access:

So why would someone use an os then, well, if you are interested in extreame optimisation you probably should not use an os. The os must wrap all functions so that they are HW independent and then thread safe (or call from different tasks), and that where the price is paid with much slower and bigger wrapped functions.

  Are you sure? yes | no