Embedded Basics – Code and Data Space Demystyfied

When developing software for a resource-constrained system it is highly recommended that developers use metrics that track code, data and RAM usage. This information can always be found within the compiler generated map file but it isn’t always necessarily a final and total value. Many compilers will calculate these values and print them to the console window during the compile process. The information displayed though isn’t always clear.

For example, when compiling a program for an ARM Cortex-M processor the output printed to the console will take a form similar to that below:

text data bss dec hex filename

0x100 0x22 0x56 377 0x178 experiment1.elf

At first glance this can look relatively intimidating although not totally so. The question that mind come to mind is what the heck do these different spaces mean? How much RAM and how much FLASH is actually being used? To understand this, it is critical to know what exactly each of these segments are and how they contribute to these totals.

The text segment tells the developer how much flash space is being allocated for code and constants for the program. This can be thought of as any variable that uses the const type qualifier, function and executable code that is generated as part of the program. For example, the following statement would add four bytes to the text segment.

const uint32_t Data = 0x14;

The data segment contains the amount of space that initialized variables are taking up in flash. This section is important to note because the initialized values for variables are stored in flash but they are copied to RAM during initialization of the system. This copying process is often referred to as the C copy down. An example of an initialized variable can be found below:

uint32_t Data_Init = 0x14;

The bss segment contains the space for any uninitialized data. This is data that will be given an initial value of 0. These are once again variables that will be stored in RAM. A simple example of uninitialized data would be as follows:

uint32_t Data_NoInit;

The remaining values in the compiler output simply state the total of the text, data and bss segments in either decimal or hexadecimal notation. Unfortunately this result really only tells how much flash space will be used for the application. To get the amount of RAM that is being used the data and bss segments need to be added together. Once this is done the developer can understand how much flash and RAM space is being utilized on the part.