Are all RAM-sections used in this linkerscript of a STM32H743 microcontroller (Cortex-M7)?

Question

I know that the RAM-memory in the latest STM32 microcontrollers contains several sections with remarkable speed differences. That's why I'm trying to wrap my head around the linkerscripts for these devices (note: arm-none-eabi-gcc toolchain). Unfortunately, the linkerscript generated by CubeMX for the STM32F767ZI just ignores different sections within RAM:

/* Specify the memory areas */
MEMORY
{
  RAM (xrw)      : ORIGIN = 0x20000000, LENGTH = 512K
  FLASH (rx)      : ORIGIN = 0x8000000, LENGTH = 2048K
}

 
STMicroelectronics seems to have done some efforts to make the linkerscript for its newest STM32H743ZI a bit more sophisticated:

/* Specify the memory areas */
MEMORY
{
  DTCMRAM (xrw)      : ORIGIN = 0x20000000, LENGTH = 128K
  RAM_D1 (xrw)      : ORIGIN = 0x24000000, LENGTH = 512K
  RAM_D2 (xrw)      : ORIGIN = 0x30000000, LENGTH = 288K
  RAM_D3 (xrw)      : ORIGIN = 0x38000000, LENGTH = 64K
  ITCMRAM (xrw)      : ORIGIN = 0x00000000, LENGTH = 64K
  FLASH (rx)      : ORIGIN = 0x8000000, LENGTH = 2048K
}

However, when I look further in the linkerscript, it seems like they're stuffing everything in the DTCMRAM! All other sections are unused...

This is the complete linkerscript:

/*
*****************************************************************************
**

**  File        : LinkerScript.ld
**
**  Abstract    : Linker script for STM32H743ZITx Device with
**                2048KByte FLASH, 1056KByte RAM
**
**                Set heap size, stack size and stack location according
**                to application requirements.
**
**                Set memory bank area and size if external memory is used.
**
**  Target      : STMicroelectronics STM32
**
**
**  Distribution: The file is distributed as is, without any warranty
**                of any kind.
**
*****************************************************************************
** @attention
**
** <h2><center>&copy; COPYRIGHT(c) 2014 Ac6</center></h2>
**
** Redistribution and use in source and binary forms, with or without modification,
** are permitted provided that the following conditions are met:
**   1. Redistributions of source code must retain the above copyright notice,
**      this list of conditions and the following disclaimer.
**   2. Redistributions in binary form must reproduce the above copyright notice,
**      this list of conditions and the following disclaimer in the documentation
**      and/or other materials provided with the distribution.
**   3. Neither the name of Ac6 nor the names of its contributors
**      may be used to endorse or promote products derived from this software
**      without specific prior written permission.
**
** THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
** AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
** IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
** DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
** FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
** DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
** SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
** CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
** OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
** OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
**
*****************************************************************************
*/

/* Entry Point */
ENTRY(Reset_Handler)

/* Highest address of the user mode stack */
_estack = 0x20020000;    /* end of RAM */
/* Generate a link error if heap and stack don't fit into RAM */
_Min_Heap_Size = 0x200;      /* required amount of heap  */
_Min_Stack_Size = 0x400; /* required amount of stack */

/* Specify the memory areas */
MEMORY
{
DTCMRAM (xrw)      : ORIGIN = 0x20000000, LENGTH = 128K
RAM_D1 (xrw)      : ORIGIN = 0x24000000, LENGTH = 512K
RAM_D2 (xrw)      : ORIGIN = 0x30000000, LENGTH = 288K
RAM_D3 (xrw)      : ORIGIN = 0x38000000, LENGTH = 64K
ITCMRAM (xrw)      : ORIGIN = 0x00000000, LENGTH = 64K
FLASH (rx)      : ORIGIN = 0x8000000, LENGTH = 2048K
}

/* Define output sections */
SECTIONS
{
  /* The startup code goes first into FLASH */
  .isr_vector :
  {
    . = ALIGN(4);
    KEEP(*(.isr_vector)) /* Startup code */
    . = ALIGN(4);
  } >FLASH

  /* The program code and other data goes into FLASH */
  .text :
  {
    . = ALIGN(4);
    *(.text)           /* .text sections (code) */
    *(.text*)          /* .text* sections (code) */
    *(.glue_7)         /* glue arm to thumb code */
    *(.glue_7t)        /* glue thumb to arm code */
    *(.eh_frame)

    KEEP (*(.init))
    KEEP (*(.fini))

    . = ALIGN(4);
    _etext = .;        /* define a global symbols at end of code */
  } >FLASH

  /* Constant data goes into FLASH */
  .rodata :
  {
    . = ALIGN(4);
    *(.rodata)         /* .rodata sections (constants, strings, etc.) */
    *(.rodata*)        /* .rodata* sections (constants, strings, etc.) */
    . = ALIGN(4);
  } >FLASH

  .ARM.extab   : { *(.ARM.extab* .gnu.linkonce.armextab.*) } >FLASH
  .ARM : {
    __exidx_start = .;
    *(.ARM.exidx*)
    __exidx_end = .;
  } >FLASH

  .preinit_array     :
  {
    PROVIDE_HIDDEN (__preinit_array_start = .);
    KEEP (*(.preinit_array*))
    PROVIDE_HIDDEN (__preinit_array_end = .);
  } >FLASH
  .init_array :
  {
    PROVIDE_HIDDEN (__init_array_start = .);
    KEEP (*(SORT(.init_array.*)))
    KEEP (*(.init_array*))
    PROVIDE_HIDDEN (__init_array_end = .);
  } >FLASH
  .fini_array :
  {
    PROVIDE_HIDDEN (__fini_array_start = .);
    KEEP (*(SORT(.fini_array.*)))
    KEEP (*(.fini_array*))
    PROVIDE_HIDDEN (__fini_array_end = .);
  } >FLASH

  /* used by the startup to initialize data */
  _sidata = LOADADDR(.data);

  /* Initialized data sections goes into RAM, load LMA copy after code */
  .data : 
  {
    . = ALIGN(4);
    _sdata = .;        /* create a global symbol at data start */
    *(.data)           /* .data sections */
    *(.data*)          /* .data* sections */

    . = ALIGN(4);
    _edata = .;        /* define a global symbol at data end */
  } >DTCMRAM AT> FLASH


  /* Uninitialized data section */
  . = ALIGN(4);
  .bss :
  {
    /* This is used by the startup in order to initialize the .bss secion */
    _sbss = .;         /* define a global symbol at bss start */
    __bss_start__ = _sbss;
    *(.bss)
    *(.bss*)
    *(COMMON)

    . = ALIGN(4);
    _ebss = .;         /* define a global symbol at bss end */
    __bss_end__ = _ebss;
  } >DTCMRAM

  /* User_heap_stack section, used to check that there is enough RAM left */
  ._user_heap_stack :
  {
    . = ALIGN(8);
    PROVIDE ( end = . );
    PROVIDE ( _end = . );
    . = . + _Min_Heap_Size;
    . = . + _Min_Stack_Size;
    . = ALIGN(8);
  } >DTCMRAM



  /* Remove information from the standard libraries */
  /DISCARD/ :
  {
    libc.a ( * )
    libm.a ( * )
    libgcc.a ( * )
  }

  .ARM.attributes 0 : { *(.ARM.attributes) }
}

Does this mean that all other sections in RAM remain unused? Why on earth would they do that?

---

If you can improve this linkerscript (and make the other RAM sections useful), please copy-paste your improvement in your answer. I would be very grateful. Please also specify how one can actually decide in the C-source code (or C++ source code) where certain data ends up in the RAM. That's still somewhat mysterious to me ^_^

Balliett

what happens when you throw in some .bss or .data to your project, can be bogus global stuff, that pushes you over the 128K? I would assume with the xrw it would then overflow into the next section. – Demise

Answer 1

With gcc, you can add a section attribute to variables. Based on that, the variable is then moved to particular session.

As an example. Let's say you have a large array:

#define BUF_SIZE 2048

__attribute__ ((section(".buffers"), used))
uint8_t pipe_buffer[BUF_SIZE];

You then add a section to the loader script and assigns it to a particular memory area (RAM_D3 in this case):

.buffers(NOLOAD) : {
    . = ALIGN(4);
    *(.buffers*)
} > RAM_D3

That way the buffers ends up in RAM_D3.

Deliladelilah

Thank you @Codo! What is the NOLOAD you put in the linkerscript? Is it an indication that this section is like the bss-section: not initialized? If that's the case, why does the bss-section start like this: .bss : {...} instead of .bss(NOLOAD) : {...}? – Balliett

Also, does this mean that STMicro expects the user to add such code to the linkerscript, otherwise all those other RAM-sections are not reacheable? – Balliett

Most likely (NOLOAD) is not needed. Loading refers to the process of loading an executable residing on disk into memory. For MCU the executable resides in FLASH. So none of the sections can be loaded. – Deliladelilah

You have several options of using the special RAM sections. 1. With a linker script as described above. 2. If a special version of malloc is provided that takes an additional parameter for selection the RAM section (the SDK for ESP32 provides such a function) 3. You assign the value 0x38000000 to an pointer. Then you have an array in RAM_D3. 4. Some else you can think of... STMicro doesn't seem to provide any specific support. If I'm not mistaken, the MCU can also use external RAM. That would change the story yet again. – Deliladelilah

Hi @Codo, So it looks like STMicro has just put those RAM-sections there in the linkerscript, but without making the linkerscript ready for their use? – Balliett

Yes. Unless there are other gcc options to move something into a particular section that I don't know of. – Deliladelilah

Thank you @Codo. Your answer has been very useful. I'll give it some time (to invoke some more input from others), then I'll mark your answer :-) – Balliett

@Balliett it is quite logical. They are connected different way to the core. Designer should decide what memory section and how to use it. It is not the application processor. Deep knowledge of the used tool (compiler) implies – Bucko

AFAIK GCC can't distribute things automatically, so you have to pick a region as a default where everything goes that is not for an explicitly specified section. – Pilch

@K.Mulier, it seems like you forgot to mark this answer as accepted (or have another interpretation of "some time") ;-) – Fifteen

@K.Mulier, it makes sense that STM provided this linker script which only uses the DTCMRAM. It's the fastest and simplest RAM. For example, you don't have to care about caches. For more advanced use cases, e.g. if you need the full amount of memory or need DMA to transfer data, you will have to understand a lot more about the architecture and have to make some specific design choices that might impact performance a lot. These choices have to be reflected in the linkerscript and might be different per use case. – Fifteen