Skip to main content
MJack.1
Associate III
June 10, 2021
Question

Issue with memory placement in Cube IDE generated project for STM32H755

  • June 10, 2021
  • 2 replies
  • 1697 views

Hi all,

I have a Cube IDE project generated for the STM32H755 Nucleo using Cube MX.

I switched out the linker script for one that I have used in other projects with this board, basically just defining some sections for large buffers in RAM. I use the same linker for both M4 and M7. (See below).

I've been getting bizarre behaviour when I write data to my sections declared in RAM.

If I inspect the .MAP file, I can see that important variables are being placed in the SRAM1 alias address 0x10000000, which conflicts with sections declared in my linker script at 0x30000000, which are also in the .map file:

.data.SystemCoreClock
 0x0000000010000000 0x4 Common/Src/system_stm32h7xx_dualcore_boot_cm4_cm7.o
 0x0000000010000000 SystemCoreClock
 .data.SystemD2Clock
 0x0000000010000004 0x4 Common/Src/system_stm32h7xx_dualcore_boot_cm4_cm7.o
 0x0000000010000004 SystemD2Clock

and later on..

.SAIBuffSection
 0x0000000030000000 0x1000 Core/Src/main.o
 0x0000000030000000 SAI_DmaTxBuf
 0x0000000030000800 SAI_DmaRxBuf

As far as I'm aware, these are the same memory areas, right?

0693W00000BafvsQAB.png 0693W00000Bafw7QAB.pngOr am I missing something fundamental here?

When I compare this with an .map file generate by visualGDB using the same linker script, I can see that it puts them in a sensible place, away from my buffers in RAM:

.data.SystemCoreClock
 0x240005cc 0x4 VisualGDB/Debug/_1_/src/Common/system_stm32h7xx_dualcore_boot_cm4_cm7.o
 0x240005cc SystemCoreClock
 .data.SystemD2Clock
 0x240005d0 0x4 VisualGDB/Debug/_1_/src/Common/system_stm32h7xx_dualcore_boot_cm4_cm7.o
 0x240005d0 SystemD2Clock
 .data.uwTickPrio
 0x240005d4 0x4 VisualGDB/Debug/_1_/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal.o
 0x240005d4 uwTickPrio

This is something I have done in several projects in this same way, using visualGDB, but when generating for cube IDE, it doesn't work. Interestingly the project generated by CubeMX for Cube IDE also has RAM linker scripts that the project doesn't reference at all...

If you need any other info from me to help, please say - I'm not sure what other info would be helpful.

Many thanks, Matt

/*
******************************************************************************
**
** File : LinkerScript.ld
**
**
** Abstract : Linker script for STM32H7 series
** 1024Kbytes FLASH and 192Kbytes 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
**
** Copyright (c) 2019 STMicroelectronics.
** All rights reserved.
**
** This software component is licensed by ST under BSD 3-Clause license,
** the "License"; You may not use this file except in compliance with the
** License. You may obtain a copy of the License at:
** opensource.org/licenses/BSD-3-Clause
**
****************************************************************************
*/
 
/* 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
{
 FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 1024K
 RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 128K
 ITCMRAM (xrw) : ORIGIN = 0x00000000, LENGTH = 64K
 SRAM1 (xrw) : ORIGIN = 0x30000000, LENGTH = 0x20000
 SRAM2 (xrw) : ORIGIN = 0x30020000, LENGTH = 0x20000
 SRAM3 (xrw) : ORIGIN = 0x30040000, LENGTH = 0x8000 
 SRAM4 (xrw) : ORIGIN = 0x38000000, LENGTH = 0x10000
}
 
/* 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 */
 } >RAM 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;
 } >RAM
 
 /* 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);
 } >RAM
 
 /* Audio buffers */
 .audio_buffers (NOLOAD) :
 {
 . = ABSOLUTE(0x30000000); 
 *(.SAIBuffSection); 
 . = ABSOLUTE(0x30002000); 
 *(.audioBufferSection); 
 . = ABSOLUTE(0x30012000); 
 __OBJECTS_SECTION_START = .; 
 *(.dspObjectsSection); 
 
 } >SRAM1 
 
 /* Patch info buffers */
 .patch_info (NOLOAD) :
 {
 . = ABSOLUTE(0x30040000); 
 *(.patchInfoSection); 
 . = ABSOLUTE(0x30042000); 
 __PARAMS_SECTION_START = .;
 *(.paramSection); 
 } >SRAM3 
 
 
 
 /* Remove information from the standard libraries */
 /DISCARD/ :
 {
 libc.a ( * )
 libm.a ( * )
 libgcc.a ( * )
 }
 
 .ARM.attributes 0 : { *(.ARM.attributes) }
}
 
 

This topic has been closed for replies.

2 replies

TDK
Super User
June 11, 2021

The GCC linker has existed for a long long time and is used by millions of people. Unlikely to be a huge bug where it doesn't respect the memory areas you've listed.

I'd double check that the linker script you're editing is the one it's actually using. Check the linker command. Put an obvious error in the linker script and see if it catches it.

The two SRAM1 areas are the same except for cache handling. But the linker should respect the one you've chosen to use. The gcc linker has no clue about the internals of the chip memory.

"If you feel a post has answered your question, please click ""Accept as Solution""."
MJack.1
MJack.1Author
Associate III
June 11, 2021

Thanks for the reply, TDK.

Both the M4 and the M7 projects are definitely using the correct linker script. If I change the section addresses in them, I can see while debugging that the addresses of the variables I have placed in those sections changes also. If I put a typo in there, it fails to build.

I'm not suggesting there's a big bug with GCC - but there's a problem somewhere, either with my linker or the generated project settings. Here are my linker settings (Nothing in the 'libraries' or 'misc' tabs) :

0693W00000BahZyQAJ.pngAny ideas where to look next?

TDK
Super User
June 11, 2021

> Any ideas where to look next?

I have no idea why the linker would be doing something other than executing your linker script. Could be missing something.

"If you feel a post has answered your question, please click ""Accept as Solution""."