2019-04-03 12:19 PM
Hi all,
I have a C++ project running fine on the STM32H7 EVAL board that I need to port to an STM32H7 Nucleo board, because it closer resembles the final hardware I will be using.
I generated a Nucleo project using CubeMX and added all the things I needed (Including FreeRTOS). I then converted the C project to a C++ project in True studio, and added all the source files, include directories, compiler flags, and linker flags.
The EVAL project linker script places all user data in RAMD1 because it has the size required to hold the 128K stack required by the RTOS. When I alter the linker file of the Nucleo project for the same reason, the program gets stuck during startup, at the point of loading the c++ global constructors :
/* Call static constructors */
bl __libc_init_array
(When I say 'gets stuck' I mean the debugger can't step over or into this line. I believe the program jumps to an undefined interrupt with an infinite loop for debugging.)
If I reduce the stack size of the RTOS and change the linker script back to placing all user data in DTCMRAM, then the program doesn't get stuck anymore.
I hope that is a clear enough explanation! I would really appreciate any help to understand what is happening and how to resolve it.
Here is my linker script:
/*
*****************************************************************************
**
** File : LinkerScript.ld
**
** Abstract : Linker script for STM32H743ZITx Device with
** 2048KByte FLASH, 128KByte 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.
**
** (c)Copyright Ac6.
** You may use this file as-is or modify it according to the needs of your
** project. Distribution of this file (unmodified or modified) is not
** permitted. Ac6 permit registered System Workbench for MCU users the
** rights to distribute the assembled, compiled & linked contents of this
** file as part of an application binary file, provided that it is built
** using the System Workbench for MCU toolchain.
**
*****************************************************************************
*/
/* 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 */
} >RAMD1 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;
} >RAMD1
/* 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);
} >RAMD1
/* Remove information from the standard libraries */
/DISCARD/ :
{
libc.a ( * )
libm.a ( * )
libgcc.a ( * )
}
.ARM.attributes 0 : { *(.ARM.attributes) }
}
Solved! Go to Solution.
2019-04-09 10:06 AM
Got it!
It was the minimum heap size in the linker script - Increased it substantially and it worked. I was led astray by the fact that I was porting the code from another project, and used the same minimum heap and stack sizes that that project has.
I have no idea how that project ever worked though, at it uses the same chip...
2019-04-03 12:34 PM
More likely Hard Faults as you touch memory you shouldn't.
Either via the stack frame, one or more RAM which needs its clock enabled, or just some inherent issue with the constructor table and the constructor functions it calls upon.
2019-04-03 12:36 PM
2019-04-03 12:58 PM
Thanks for the reply, Clive!
EDIT: I just saw your link - I will read it properly and report back :)
In section 2.1.7 of the RM0433 manual it says: 'Upon reset, clocks to blocks such as peripherals and some memories are disabled (except for the SRAM, DTCM, ITCM and Flash memory).'
In the startup routine, the only relevant code executed before the 'libc_init_array' is as below. I can't see anything that would suggest the RAMD1 doesn't have an active clock. Plus I have used this ram successfully in the same way in the past for DMA access.
void SystemInit (void)
{
/* FPU settings ------------------------------------------------------------*/
#if (__FPU_PRESENT == 1) && (__FPU_USED == 1)
SCB->CPACR |= ((3UL << 10*2)|(3UL << 11*2)); /* set CP10 and CP11 Full Access */
#endif
/* Reset the RCC clock configuration to the default reset state ------------*/
/* Set HSION bit */
RCC->CR |= RCC_CR_HSION;
/* Reset CFGR register */
RCC->CFGR = 0x00000000;
/* Reset HSEON, CSSON , CSION,RC48ON, CSIKERON PLL1ON, PLL2ON and PLL3ON bits */
RCC->CR &= (uint32_t)0xEAF6ED7F;
/* Reset D1CFGR register */
RCC->D1CFGR = 0x00000000;
/* Reset D2CFGR register */
RCC->D2CFGR = 0x00000000;
/* Reset D3CFGR register */
RCC->D3CFGR = 0x00000000;
/* Reset PLLCKSELR register */
RCC->PLLCKSELR = 0x00000000;
/* Reset PLLCFGR register */
RCC->PLLCFGR = 0x00000000;
/* Reset PLL1DIVR register */
RCC->PLL1DIVR = 0x00000000;
/* Reset PLL1FRACR register */
RCC->PLL1FRACR = 0x00000000;
/* Reset PLL2DIVR register */
RCC->PLL2DIVR = 0x00000000;
/* Reset PLL2FRACR register */
RCC->PLL2FRACR = 0x00000000;
/* Reset PLL3DIVR register */
RCC->PLL3DIVR = 0x00000000;
/* Reset PLL3FRACR register */
RCC->PLL3FRACR = 0x00000000;
/* Reset HSEBYP bit */
RCC->CR &= (uint32_t)0xFFFBFFFF;
/* Disable all interrupts */
RCC->CIER = 0x00000000;
/* Change the switch matrix read issuing capability to 1 for the AXI SRAM target (Target 7) */
*((__IO uint32_t*)0x51008108) = 0x00000001;
#if defined (DATA_IN_ExtSRAM) || defined (DATA_IN_ExtSDRAM)
SystemInit_ExtMemCtl();
#endif /* DATA_IN_ExtSRAM || DATA_IN_ExtSDRAM */
/* Configure the Vector Table location add offset address ------------------*/
#ifdef VECT_TAB_SRAM
SCB->VTOR = D1_AXISRAM_BASE | VECT_TAB_OFFSET; /* Vector Table Relocation in Internal ITCMSRAM */
#else
SCB->VTOR = FLASH_BANK1_BASE | VECT_TAB_OFFSET; /* Vector Table Relocation in Internal FLASH */
#endif
}
2019-04-04 10:30 AM
Hi Again @Community member ,
I had a read up on RCC->AHB2ENR->SRAMD1EN, which enables the RAMD1 block, and RCC->CR->D1CKRDY, which indicates that the module has a clock.
Stepping through the startup script, I can see that D1CKRDY is set all the way through. SRAMD1EN however, is not. I therefore added the following line to the systemInit function:
__HAL_RCC_D2SRAM1_CLK_ENABLE();
And now I can see that SRAMD1EN is set before calling __libc_init_array. However, the program still cannot get past __libc_init_array.
When I pause the debugger, I see the program counter is here:
void _exit (int status)
{
_kill(status, -1);
while (1) {} /* Make sure we hang here */
}
Thanks for your help so far - any further ideas of what the issue could be?
Matt
2019-04-04 12:09 PM
Not sure how the GNU/GCC C++ libraries manage stuff. You might want to look at the behaviour of the malloc/free, or new operations, and how they related heap top and stack base to determine available heap memory. So perhaps syscalls.c and _sbrk()
Look at the value of LR held by the _exit() function, to see where the call came from.
Go through the constructors to see which one failed.
2019-04-04 01:50 PM
Cheers. I used LR to find my way back to the last instruction and the disassembly looks like it was atof().
If I step through the libc_init_arrray disassembly I can see that it iterates through the array and at some point just jumps to _exit.
I would assume it's a memory problem, except there's plenty of memory available. Not really sure where to go from here.
2019-04-09 10:06 AM
Got it!
It was the minimum heap size in the linker script - Increased it substantially and it worked. I was led astray by the fact that I was porting the code from another project, and used the same minimum heap and stack sizes that that project has.
I have no idea how that project ever worked though, at it uses the same chip...