ZI Data extends area assigned in linker script

Ok Thank you, also for the tip with the formating.

You think it will be necessary to write a test application to check if b = true?

a) Does RW_IRAM1a area automatically fallback to use the HEAP ? => yes
b) If a=yes, is it ensured, that the memory used by zi is reserved and not allocateable via malloc / c++ new operator. ?

Fall back how exactly? The heap's memory arena starts as a singular linear region, some effort with the setup and the allocator would be required for it to be split amongst multiple regions.

If you don't want to zero initialize the SDRAM it should be a NOINIT region.

The linker defines the location of the HEAP and the STACK, neither overlap, nor do any other static allocations made by the linker. A failure in the code can cause the stack to descend down and through the heap. ie local/auto variables accumulate beyond the accommodations made for them, figure recursion, or poor grasp of algorithm.

In my experience (RW Data + ZI Data) includes both the heap and the stack, and the heap is the pool from which malloc (and presumably new) draw from.

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.