Hello,
i read a little bit about zi-data in the other threads here.
I'm glad that it's possible to ask such "easy" questions which could also be answered "just" by reading a few hundred pages of documentation. ;-)
Now reviewing the project i stepped over following question:
This is the linker script:
LR_IROM1 0x08000000 0x00200000 { ; load region size_region ER_IROM1 0x08000000 0x00200000 { ; load address = execution address *.o (RESET, +First) *(InRoot$$Sections) .ANY (+RO) } RW_IRAM1a 0x20000000 0x00025000 { ; RW data .ANY (+RW +ZI) } RW_IRAM1b 0x20025000 0x00025000 { *.o(STACK, +Last) }
; [20160314_HeapInSdRam_NewCode] RW_SDRAM 0xD0000000 0x00780000 { ; 8 MB *.o (HEAP, +First) } ; [/20160314_HeapInSdRam_NewCode]
}
This is the map file: Total RO Size (Code + RO Data) 1524588 (1488.86kB) Total RW Size (RW Data + ZI Data) 8038188 (7849.79kB) Total ROM Size (Code + RO Data + RW Data) 1532760 (1496.84kB)
Gosh, that formating! Conclussion: I see that the size allocated for RW+ZI-Data (RW_IRAM1a) is way too small to hold all the zi data stated in the map file. The project is running fine. How can this be true?
I have further questions in my mind:
a) Does RW_IRAM1a area automatically fallback to use the HEAP ? b) If a=yes, is it ensured, that the memory used by zi is reserved and not allocateable via malloc / c++ new operator. c) if b=false, it may happen at some milestone in the project lifetime that bad memory errors occur?! d) IF ZI-Data would just overlap overwriting the Stack araea (RW_IRAM1b) the program is unlikely to run stable?!
Can anybody answer this? Thanks in advance!
Where the HEAP is in it's own memory region, a stack failure would typically plough directly into the locale/statics rather than traverse the heap first.
The .MAP file would give a sense of where things are to each other in a relative way.
You wrote: > Fall back how exactly?
This is the linker File:
LR_IROM1 0x08000000 0x00200000 { ; load region size_region ER_IROM1 0x08000000 0x00200000 { ; load address = execution address *.o (RESET, +First) *(InRoot$$Sections) .ANY (+RO) } RW_IRAM1a 0x20000000 0x00025000 { ; RW data .ANY (+RW +ZI) } RW_IRAM1b 0x20025000 0x00025000 { *.o(STACK, +Last) } ; [20160314_HeapInSdRam_NewCode] RW_SDRAM 0xD0000000 0x00780000 { ; 8 MB *.o (HEAP, +First) } ; [/20160314_HeapInSdRam_NewCode] }
This is the MAP file:
Total RO Size (Code + RO Data) 1526544 (1490.77kB) Total RW Size (RW Data + ZI Data) 8038188 (7849.79kB) Total ROM Size (Code + RO Data + RW Data) 1534664 (1498.70kB)
As you see the RW/ZI Data is assigned to area RW_IRAM1a with size 0x25000. The map file states that RW+ZI Data is BIGGER than this size. My question was: How can this work?
Now you said
>> You're directing the heap initialization into the SDRAM so the the bulk of the ZI is likely there
That's why i assumed:
a) Does RW_IRAM1a area automatically fallback to use the HEAP ? => yes
Actually, as the RW_IRAM1a is not big enough to hold all the ZI Data it shouldn't work. But it does. That's what i dont understand. It can only work if the linker automatically ignores the ZI assignment done in the linker file and puts it to sdram on its own. (?)
Ok i learned about the difference between compressed size of the rw data and zi data in the flash and the uncompressed size in the ram.
For a trial I set size of RW_IRAM1a to 0 in the linker script and the linker says:
.\Bin\RehmMNr1\RehmMNr1Simu.axf: Error: L6407E: Sections of aggregate size 0x577c bytes could not fit into .ANY selector(s).
So this shows the RW/ZI size in the ram is 0x577c bytes (the size it fails to reserve).
It seems there is not automatic fallback to other region.
Still i wonder what this final size of 8038252 Bytes at the end of the map file is.