Application Flash / RAM size

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Application Flash / RAM size

7,616 Views
lpcware-support
Senior Contributor I

Size information produced by build

As part of the build process, information on the size of your application will normally be displayed at the end of the build log in the Console view. This is done by a post-build step invoking the arm-none-eabi-size utility....

  text   data   bss    dec     hex   filename
  2624    524    32    3180     c6c   LPCXpresso1768_systick_twinkle.axf

[All numbers are in bytes.]

  • text - shows the code and read-only data in your application (in decimal)

  • data - shows the read-write data in your application (in decimal)

  • bss - show the zero initialized ('bss' and 'common') data in your application (in decimal)

  • dec - total of 'text' + 'data' + 'bss' (in decimal)

  • hex - hexadecimal equivalent of 'dec'

Typically:

  • the flash consumption of your application will then be text + data

  • the RAM consumption of your application will then be data + bss

Remember that the RAM consumption provided by this is only that of your global data. It will not include any memory consumed by your stack and heap when your application is actually executing.

You can also manually run the arm-none-eabi-size utility on both your final application image, or on individual object files.

To view the size of the image, right click over the .axf file in the Debug or Release subdirectory of your application project and select the Binary Utilities -> Size option. To view the size of an individual object file, select the appropriate .o file in the Debug\src or Release\src subdirectory of the project and again select the Binary Utilities -> Size option.

Note: Looking at the size of the AXF file on disk does not provide any information as to how much Flash/RAM space your application will occupy when downloaded to your MCU. The AXF file contains a lot more information than just the binary code of your application, for example the debug data used to provide source level information when debugging, that is never downloaded to your MCU.


Linker Memory Usage Option

Any project created with LPCXpresso IDE v8.1 or later will add the option -print-memory-usage to the link step. This will generate memory usage information of the following form:

Memory region      Used Size      Region Size      %age Used  

MFlash256:           11160 B      256 KB            4.26%
Ram0_16:               340 B       16 KB            2.08%
Ram1_16:                0 GB       16 KB            0.00%  
Ram2_4:                 0 GB        4 KB            0.00%
Finished building target: lpc1549_hello.axf


Linker map files

The linker option "-map" option, which is enabled by default by the project wizard when a new project is created, allows you to analyse in more detail the contents of your application image. When you do a build, this will cause a file called <application>.map to be created in the Debug (or Release) subdirectory, which can be loaded into the editor view. This contains a large amount of information, including:

  • A list of archive members (library objects) included and why
  • A list of discarded input sections (because they are unused and the linker option --gc-sections is enabled).
  • The location, size and type of all code, data and bss items that have been placed in the image.


Other utilities

The arm-none-eabi-nm utility can sometime be useful when looking at the size of your application, as it can produce some of the information provided in the linker map file but in a more concise form. For example:

arm-none-eabi-nm -S --size-sort -s project.axf

produces a list of all the symbols in an image, their sizes and their addresses, listed in size order. For more information on this utility, please see the GNU binutils documentation.

Note that you can run arm-none-eabi-nm as a post-build step, or else open a command shell using the status bar shortcuts.

1 Reply

3,667 Views
ianholmes
Contributor II

My understanding is that bss contains the RAM initialisation for values and other constants. So this would mean that the flash size is text + bss and the ram is data, possibly plus bss.

Is there an error in the original infomation given, or am I missing something?

0 Kudos