How to interpret MEMORY areas in STM32H747XIHX_FLASH.ld file

[TurtleBeach]

The H747I-DISCO specs say 2MB Flash and 1MB RAM. From that, I am trying to understand what the start addresses of both areas are.

I see that for both processors (M7 and M4) two .ld files get created:STM32H..._FLASH.ld and STM32..._RAM.ld, for a new STM32 project, with default peripheral settings, generated by CubeIDE 1.1 with CubeMX 5.4

In the FLASH file, I see a MEMORY structure that contains

{
FLASH (rx)      : ORIGIN = 0x08000000, LENGTH = 1024K
RAM (xrw)      : ORIGIN = 0x20000000, LENGTH = 128K
ITCMRAM (xrw)      : ORIGIN = 0x00000000, LENGTH = 64K
}

My questions:

1) If 0x08000000 is in fact the start address of FLASH, why is the length only 1024K. Similarly for RAM - if 0x20000000 is the start address, why is the length 128K.

More to the point, if I change the LENGTH values to 2048 and 1024 to correspond to what is supposedly on the board, is that valid, and is that the way to use all memory available?

2) Why is there a separate RAM.ld file, which has completely different values for FLASH and RAM:

MEMORY
{
FLASH (rx)      : ORIGIN = 0x24000000, LENGTH = 256K
RAM (xrw)      : ORIGIN = 0x24040000, LENGTH = 256K
}

I need to want to specify larger heap and stack sizes than the defaults, and in fact want to get close to the maximum possible. But I would like to understand the role of these structures before I just start changing values.

Thanks,

[Tesla DeLorean]

#2 Probably so the entire executable image can be downloaded and executed in RAM, ie copied from one core, into the the other.

For power, speed, or convenience? Could be compressed into an area of FLASH, allowing a more linear 2MB of FLASH for the primary image

You're just going to have create your own linker script that fully describes all the regions you want to use. You'll need to facilitate the setup and unpacking in startup.s, and deal with whatever clown show allocation routine they have in __sbrk() to separate heap and stack regions/expectations.

[Tesla DeLorean · Accepted solution]

Watch also that SRAM clocks are enabled

https://community.st.com/s/question/0D50X0000A7XIH1SQO/want-to-store-data-in-sram-d2-domain-what-is-missing-to-avoid-hard-fault

https://community.st.com/s/question/0D50X0000BeaQbNSQU/how-to-assign-ram-memories-to-data-bss-and-stack-and-heap-sections

[TurtleBeach]

@Community member

Thanks. Following your suggestions about clocks, and adding a region to the linker script (after wasting several hours looking for the document that identifies the start addresses for the H7 regions - AN4891 for anyone else needing to know where the various regions start)​ , I as able to map heap space to the AXI SRAM:

MEMORY
{
FLASH (rx)      : ORIGIN = 0x08000000, LENGTH = 1024K
RAM (xrw)      : ORIGIN = 0x20000000, LENGTH = 128K
SRAM (xrw)     : ORIGIN = 0x24000000, LENGTH = 512K
ITCMRAM (xrw)      : ORIGIN = 0x00000000, LENGTH = 64K
}
...
 ._user_heap_stack :
  {
    . = ALIGN(8);
    PROVIDE ( end = . );
    PROVIDE ( _end = . );
    . = . + _Min_Heap_Size;
    . = . + _Min_Stack_Size;
    . = ALIGN(8);
  } >SRAM
 

and magically everything worked (my code, which needed to allocate ~200KB of memory for a large dynamic structure).

Now if I just remember tomorrow what I did tonight..