Can anyone tell me the meaning of Zero Initialized Data (ZI Data). Do they actually take up RAM maps. It would be best explained in practical point of view, ie is this global or local type of variable. I use Keil and Cortex-M0.
I declared variable within code that point to FLASH region as part of emulated ROM code. However according to the .map, it shown that ZI Data = 1024 Byte which is 8 * 128 = 1024 Byte. This lead to incorrect conclusion about RAM size as .map indicated.
EEEDATA_TYPE EEEFLASH[8] __attribute__((at(0x10007C00U))); //this instruct linker to align data to the specific FLASH location. Keil specfic.
Is there nice tutorial or PDF that explain how to use / meaning if RO, RW and ZI data and how to manage them where necessary.
http://www.keil.com/support/man/docs/armlink/armlink_Cdeffifa.htm http://www.keil.com/support/man/docs/armlink/armlink_Bhcghded.htm http://www.keil.com/support/man/docs/armlink/armlink_Cdeejjhi.htm
Local variables consume Stack; so the ZI is not for them.
www.lmgtfy.com
Of course zero-initialized variables consumes RAM. It's just that their initial value is zero, so the startup code can initialize them with a memset() while normal initialized variables needs that the initial values are stored in the code, and copied into RAM on startup.
As you should have realized from Andy's Google link, the termi ZI or Zero Initialized Data really are standard concepts. The C standard requires that any global variable must always be given an initial value even if the source code doesn't supply an explicit value.
Auto variables are stored on the stack, and they do not get any initial value unless you do an initial assign. So they are not part of the ZI memory region.
Andrew Neil, this is rather cheeky, I have indeed google the web and did not fine anything useful, until earlier response provided very good response.
I'm hard working engineer and I find your comment out of order. Please do not bother me again.
R.
Hi Per Mestermark
Thank kindly for the response and very much appericated, what puzzle me is that the code I put there point to FLASH region of the memory (not RAM) and yet according to .MAP it is counted toward to ZI-Data and thus provide misleading results in ROM and RAM consumption. I wondered if there is bug within the tool that generate the .map.
I think you might be confusing the toolchain by using the "at" attribute. The compiler doesn't know anything about the actual memory map of your device so it places things into segments according to the basic rules. Roughly, the compiler will generate segments for code, constants, zi-data and initialized data.
The linker groups these segments into regions and at that point the bootloader that does the copying and zero-init gets added to your code. I'm not sure what exactly happens at that point, it's possible that the init code will actually attempt to memset your eeprom variable to zero. If you single step through your code from the reset vector in assembly mode you can see where that is taking place.
I usually generate a separate segment in the scatter-load file and use segment assignment attributes instead of the "at" attribute. It's a little more work but it ensures that both the compiler and linker work together.
Here's an earlier question of mine that shows the syntax for what you're trying to do. I had the additional problem that my variable was too small to ever be not initialized. Anything smaller than 8 bytes is forced to be initialized by the RealView compiler tools. I answer my own question at the end:
http://www.keil.com/forum/18925/
Andrew
Check this pdf. @ google: ARM Compiler toolchain Version 4.1 Using the Linker
Chapter 4 Image structure and generation