2021-06-10 02:13 PM
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?
Or 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) }
}
2021-06-10 07:04 PM
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.
2021-06-11 12:28 AM
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) :
Any ideas where to look next?
2021-06-11 07:12 AM
> 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.