LPCXpresso Flash/Ram Size and Memory Management

Application Flash / RAM size

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 – hexidecimal equivalent of ‘dec’


  • 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.


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.

Stack problems

There is no stack checking on the Cortex-M families, so you have to be careful where you place the stack, program data, and the heap (e.g. malloc() space).

If you are using the standard (provided) linker scripts, the stack is placed at the top of RAM, program data is at the bottom on RAM, and the heap immediately after that.

If you are using a lot of stack, it can grow into the heap or even the program data space. If the stack has ‘overflowed’ into those spaces, when you write to the heap/program data it can overwrite values on the stack and thus corrupt it.

The stack is used for both your application AND any interrupts that may be firing (including nested interrupt), so you need to ensure there is enough space for the worst-case scenario.

Also, check that you are not allocating large amounts of data on the stack (e.g. allocating a local array, as this will be placed on the stack).


Heap allocation/checking

By default, the heap used by Redlib_v2’s malloc family of routines grows upwards from the end of the user data in RAM up towards the stack (a “one region memory model”).

When a new block of memory is requested, the memory allocation code will make a call to the following function:

unsigned __check_heap_overflow (void * new_end_of_heap)

The default version of this function compares the value of the proposed new end of the heap against the stack pointer and will return one of the following values…

  • 1 – Heap will overflow into stack
    0 – Heap still OK

If 1 is returned, malloc will set errno to ENOMEM and return a null pointer to the caller

It is possible for the user to modify heap setup such that the heap is placed in different region of memory to the stack (a “two region memory model”). To do this, the user will need to…

  1. Modify the setting of the “_pvHeapStart” variable created within the managed linker script, which is used to mark the starting location for the heap.
  2. Provide their own implementation of __check_heap_overflow(), to replace the one pulled in from the Redlib nohost/semihost library variant.

Note that Redlib_v2 uses the variable “__end_of_heap” to keep track of the end of the heap. Be aware though that this does not necessarily detail the maximum extent of the heap, only its current extent.


Ref: http://support.code-red-tech.com/

About tungsys
i am OVERLORD ! i am READY !

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: