cancel
Showing results for 
Search instead for 
Did you mean: 

Issue with memory placement in Cube IDE generated project for STM32H755

MJack.1
Associate III

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) }
}
 
 

3 REPLIES 3
TDK
Guru

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
Associate III

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
Guru

> 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".