Stop NXP / IAR SDK from using excessive code space for predefined values.

cancel
Showing results for 
Search instead for 
Did you mean: 

Stop NXP / IAR SDK from using excessive code space for predefined values.

Jump to solution
475 Views
rickstuart
Contributor V

In our NXP kl03 processor project, I see where 160 bytes of RO memory (assumed to be program memory) has been reserved for data.  When I make a list file of the source file accused of causing this RO memory reservation for data, I see it is due to a number of type uint16_t variables assigned values in a header file:

uint16_t offset_for_a = 0;
uint16_t offset_for_b= sizeof(image_a);
uint16_t offset_for_c = 128;
uint16_t offset_for_d = sizeof(image_c) + 128;

If I remove both the 2nd and 4th line from the above code, the RO memory reservation drops to zero for the source file which includes the above header information.  If I leave either the 2nd or 4th line (just one but not both), the RO memory reservation jumps to 160 bytes.

"image_a" is of type structure containing 26 uint16_t values.

"image_c" is of type structure containing 3 uint16_t values.

So, then, why has the NXP / IAR SDK wasted 160 bytes of precious code space?

Labels (2)
0 Kudos
1 Solution
317 Views
BlackNight
NXP Employee
NXP Employee

Hi Rick,

first off, this has nothing to do with the SDK. This is more a consequence how ANSI C is defined (with the requirement to initialize data during the startup code) and how the toolchain (linker) is dealing with it.

I think text, data and bss: Code and Data Size Explained | MCU on Eclipse  has part of an answer for you.

if you have something like

int32_t a = 0x12345678;

then this will consume 4 bytes of RAM (for the variable), 4 bytes FLASH for the constant (0x12345678) plus some code (FLASH) in the startup code to copy that constant to the variable space. To copy that constant to the variable, typically the library/startup code uses some information like

{destination address in RAM}{data address in FLASH}{size of data in FLASH}

This all adds up to some extend. I cannot say if this really is the 160 Bytes you see (with all the alignment maybe), but my best guess is that it would be close to the 100 bytes or so.

I hope this helps,

Erich

View solution in original post

0 Kudos
4 Replies
317 Views
bobpaddock
Senior Contributor III

To add to what Erich said, variables should not be initialized in headers.

Does that create the same variable in each compilation unit (probably not if we quote the standard)?
Does illustrate the point.

Variables at file scope, such as a header do not need to be initialized to zero, they will be assigned to the bss that does get zeroed at reset.  There are some safety standards that do require setting all variables at create to a value, even zero.

0 Kudos
317 Views
rickstuart
Contributor V

Its more convoluted than simply accusing “sizeof” of causing the problem.  I can simply  go from assigning 1 variable a numerical value to assigning 2 variables a numerical value in the header file and cause the map file report to change from using nothing to 160 bytes of RO data memory.

0 Kudos
317 Views
rickstuart
Contributor V

I keep amending my observations.  But I keep finding simpler ways to trigger the consumption of 160 bytes of RO memory.

It turns out that simply initializing any of the uint16_t variables to something other than zero  in the header will cause the extra 160 bytes of RO memory data consumption to show up. 

Why is that?

0 Kudos
318 Views
BlackNight
NXP Employee
NXP Employee

Hi Rick,

first off, this has nothing to do with the SDK. This is more a consequence how ANSI C is defined (with the requirement to initialize data during the startup code) and how the toolchain (linker) is dealing with it.

I think text, data and bss: Code and Data Size Explained | MCU on Eclipse  has part of an answer for you.

if you have something like

int32_t a = 0x12345678;

then this will consume 4 bytes of RAM (for the variable), 4 bytes FLASH for the constant (0x12345678) plus some code (FLASH) in the startup code to copy that constant to the variable space. To copy that constant to the variable, typically the library/startup code uses some information like

{destination address in RAM}{data address in FLASH}{size of data in FLASH}

This all adds up to some extend. I cannot say if this really is the 160 Bytes you see (with all the alignment maybe), but my best guess is that it would be close to the 100 bytes or so.

I hope this helps,

Erich

0 Kudos