We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
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.