Electronic – How to find out at compile time how much of an STM32’s Flash memory and dynamic memory (SRAM) is used up

flashmicrocontrollerramstm32

I have the answer for Flash memory, but the RAM question still eludes me.

Arduino has this super nice feature which displays flash and RAM usage right at compile time. Ex. in the image below you can see that this Arduino program uses 2084 bytes of flash (6%) and that global and static variables use 188 bytes (9%) of dynamic memory, or SRAM.

When I compile a simple blink program on an STM32F103RB Nucleo dev board in the System Workbench IDE I'd like to know the same thing: how much Flash and RAM is used, and how much is remaining?

When building completes, System Workbench shows:

Generating binary and Printing size information:
arm-none-eabi-objcopy -O binary "STM32F103RB_Nucleo.elf" "STM32F103RB_Nucleo.bin"
arm-none-eabi-size "STM32F103RB_Nucleo.elf"
   text    data     bss     dec     hex filename
   2896      12    1588    4496    1190 STM32F103RB_Nucleo.elf

When I look at the binary output file, "SW4STM32/Debug/STM32F103RB_Nucleo.bin", I see it is 2908 bytes, which is the sum of text + data. Therefore, that must be my Flash usage! Since I have 128KB of Flash, that means I am using 2908/(128*1024) = 2% of the total Flash space.

But how do I figure out how much SRAM my global and static variables are using, and how much is available for local variables (like Arduino shows)?

I don't have a clue what any of this stuff means yet, but if this is helpful to help you help me, here is the output from objdump -h STM32F103RB_Nucleo.elf:

$ objdump -h STM32F103RB_Nucleo.elf

STM32F103RB_Nucleo.elf:     file format elf32-little

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .isr_vector   0000010c  08000000  08000000  00010000  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  1 .text         00000a1c  0800010c  0800010c  0001010c  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  2 .rodata       00000028  08000b28  08000b28  00010b28  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 .init_array   00000004  08000b50  08000b50  00010b50  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  4 .fini_array   00000004  08000b54  08000b54  00010b54  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  5 .data         00000004  20000000  08000b58  00020000  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  6 .bss          00000030  20000004  08000b5c  00020004  2**2
                  ALLOC
  7 ._user_heap_stack 00000604  20000034  08000b5c  00020034  2**0
                  ALLOC
  8 .ARM.attributes 00000029  00000000  00000000  00020004  2**0
                  CONTENTS, READONLY
  9 .debug_info   00006795  00000000  00000000  0002002d  2**0
                  CONTENTS, READONLY, DEBUGGING
 10 .debug_abbrev 000013b2  00000000  00000000  000267c2  2**0
                  CONTENTS, READONLY, DEBUGGING
 11 .debug_loc    00000d0f  00000000  00000000  00027b74  2**0
                  CONTENTS, READONLY, DEBUGGING
 12 .debug_aranges 000002e0  00000000  00000000  00028888  2**3
                  CONTENTS, READONLY, DEBUGGING
 13 .debug_ranges 00000378  00000000  00000000  00028b68  2**3
                  CONTENTS, READONLY, DEBUGGING
 14 .debug_macro  00001488  00000000  00000000  00028ee0  2**0
                  CONTENTS, READONLY, DEBUGGING
 15 .debug_line   00003dcc  00000000  00000000  0002a368  2**0
                  CONTENTS, READONLY, DEBUGGING
 16 .debug_str    00066766  00000000  00000000  0002e134  2**0
                  CONTENTS, READONLY, DEBUGGING
 17 .comment      0000007f  00000000  00000000  0009489a  2**0
                  CONTENTS, READONLY
 18 .debug_frame  00000610  00000000  00000000  0009491c  2**2
                  CONTENTS, READONLY, DEBUGGING

Best Answer

The information you need is all in the output from size (aka arm-none-eabi-size):

   text    data     bss     dec     hex filename
   2896      12    1588    4496    1190 STM32F103RB_Nucleo.elf

text is the size of all code in your application.
data is the size of initialized global variables. It counts against both flash memory and RAM, as it's copied from flash to RAM during startup.
bss is the size of global variables which are initialized to zero (or are uninitialized, and hence default to zero). They're stored in RAM only.
dec and hex are the sum of text + data + bss in decimal and hexadecimal. This value doesn't really mean much on a microcontroller, so it should be ignored. (In environments where a program must be loaded into memory before running, it would be the total memory footprint of the program.)

To calculate the RAM usage of your program, add the data and bss columns together.

To calculate the FLASH usage of your program, add text and data.

Related Solutions

How to stock variables in FLASH memory

The short answer is to declare your variable with the const keyword. If your MCU actually remembers the value of your const variable (i.e. your sine computation actually works), it pretty much has to be stored in flash memory, otherwise it would be lost at the first reboot after programming.

The long answer has to do with linker script. These scripts are MCU-dependant and tell the linker where to put what. Usually, this script is provided by the IDE, but you can write your own. On my STM32F4 setup, my linker script starts with a such a statement:

MEMORY
{
    FLASH (rx)      : ORIGIN = 0x08000000, LENGTH = 1024K
    RAM (xrw)       : ORIGIN = 0x20000000, LENGTH = 128K
    CCMRAM (xrw)    : ORIGIN = 0x10000000, LENGTH = 64K
    MEMORY_B1 (rx)  : ORIGIN = 0x60000000, LENGTH = 0K
}

It says that the flash starts at address 0x08000000 and the RAM at address 0x20000000. These addresses can be found in the datasheet where the memory map is described. The rest of the script can get involved, but at some point something along these lines will be present:

.text :
{
    . = ALIGN(4);
    *(.text)           /* .text sections (code) */
    *(.rodata)         /* .rodata sections (constants, strings, etc.) */
    . = ALIGN(4);
    _etext = .;        /* define a global symbols at end of code */
} >FLASH

This says that all .text sections (that's how the compiler calls code section) and .rodata sections (that's how the compiler calls const variables) are to be put in the flash section.

As suggested above, the .map file is the primary way you can check what the linker puts where. You tell the linker to generate it using this option:

arm-eabi-gcc -Wl,-Map=my_program.map ...

You can search for your symbole inside this map file, see at which address it has been stored and check that against the memory map specified in the MCU datasheet.

Electronic – How to overwrite flash memory on STM32L series

Some types of non-volatile memory device use error-correcting logic which adds an extra few bits to each programmable chunk (e.g. 5 bits per 16, 6 per 32, 7 per 64, 8 per 128, etc.) Generally the error correction code is chosen so that all bits blank is a valid representation; in some cases, but not all, it may also be chosen such that all bits programmed is also a valid combination. For simplicity, I'll assume a code with which guards each group of 4 bits with 3 guard bits. Compute the three guard bits guard bit as being the xor of either data bits 0+1+3, 0+2+3, or 1+2+3. I'll also assume that a blank word is zero.

The 16 possible code values are thus

3210 ABC    3210 ABC    3210 ABC    3210 ABC
0000 000    0100 011    1000 111    1100 100
0001 110    0101 101    1001 001    1100 010
0010 101    0110 110    1010 010    1110 001
0011 011    0111 000    1011 100    1111 111

When a memory nybble is read, the system can see what bits ABC should be according to the table. If one of the seven bits in the word is misread, the combination of ABC bits that don't match the computed value will indicate which bit was wrong.

Suppose a memory system used the 16-bit code shown above, and one wanted to overwrite a byte value of 1110 (ECC bits 001) with a value of 1000 (ECC bits should be 111). The net effect would be that the system would write 1000 with ECC bits of 001. When the data is read back, the system would see that for a value of 1000, the ECC bits should be 111 but are instead 001. The fact that bits A and B are wrong means bit 0 of the data was wrong and should be flipped; the system would thus read the value as 1001 (whose ECC is correctly 001).

In most cases, there should be enough flexibility in the design of an error-correcting code to permit both all-bits-clear and all-bits-set to be regarded as valid combinations. Some systems do not do so, however. If an error-correcting code would require an all-bits-programmed word to have two or more of the ECC bits blank, then an attempt to obliterate a word which has those bits programmed would likely visibly fail; attempts to program many other values would likely yield a state which was only one bit error away from failure rather than two.

I really wish memory designers would allow for data to be obliterated even if they don't allow most other overwriting patterns. Especially with NAND flash, it would make some operations a lot easier.

Best Answer

Related Solutions

How to stock variables in FLASH memory

Electronic – How to overwrite flash memory on STM32L series

Related Topic