STM32L4 SystemCoreClock access crashes the program during HAL initialization

Question

I'm trying to blink an LED on a Nucleo-L476 with CubeMX and ST's HAL. It worked perfectly on Windows (System Workbench). Now, I'm trying to do the same on Linux with CubeMX and Qt Creator (my favorite IDE) and OpenOCD. I am now able to compile and debug the target.

However, the program crashes during HAL initialization. More precisely, when it tries to access the SystemCoreClock variable. The following code is called from HAL_Init(); in main():

__weak HAL_StatusTypeDef HAL_InitTick(uint32_t TickPriority)
{
 uint32_t tickNum=123, *ptr1=NULL, *ptr2=NULL; // Added by me to debug
 ptr1 = &tickNum; // Added by me to debug
 ptr2 = &SystemCoreClock; // Added by me to debug
 tickNum = SystemCoreClock; // Added by me to debug *** crash here ***
 /* Configure the SysTick to have interrupt in 1 ms time basis */
 HAL_SYSTICK_Config(SystemCoreClock/1000); // *** Crash here ***
 /* Configure the SysTick IRQ priority */
 HAL_NVIC_SetPriority(SysTick_IRQn, TickPriority ,0);
 /* Return function status */
 return HAL_OK;
}

I could replace SystemCoreClock by a constant, but the variable needs to be modified further down the line anyway. SystemCoreClock is declared in system_stm32l4xx.h and defined in system_stm32l4xx.c. Both files are part of the project.

** extern variable SystemCoreClock seems to have two different addresses.

Normal stuff (ptr1 == &ticknum and *ptr1 == ticknum):

(gdb) p &tickNum
3ドル = (uint32_t *) 0x20017fdc
(gdb) p ptr1
4ドル = (uint32_t *) 0x20017fdc
(gdb) p *ptr1
5ドル = 123

Strange stuff (ptr2 != &SystemCoreClock and *ptr2 != SystemCoreClock):

(gdb) p &SystemCoreClock
6ドル = (uint32_t *) 0x20000004 <SystemCoreClock>
(gdb) p ptr2
7ドル = (uint32_t *) 0x681b4b20
(gdb) p *ptr2
8ドル = 0

When I say 'crash', I mean the program falls in an infinite loop in startup_stm32l476xx.s:

/**
 * @brief This is the code that gets called when the processor receives an
 * unexpected interrupt. This simply enters an infinite loop, preserving
 * the system state for examination by a debugger.
 *
 * @param None
 * @retval : None
*/
 .section .text.Default_Handler,"ax",%progbits
Default_Handler:
Infinite_Loop:
 b Infinite_Loop

Trying to narrow down the search, I noticed that a variable declared outside a function is not properly accessed from within the function:

uint32_t dummyVar = 123;
void dummyFunc()
{
 uint32_t loc = 123;
 uint32_t *p = &loc;
 p = &dummyVar; // Debugger says &dummyVar = 0x20000004 and p = 0x011a3b01
 __asm("nop");
 __asm("nop");
 __asm("nop");
 loc = dummyVar; // *** Crash here
}

The variable p here points outside the RAM, which starts at 0x20000000. The nop instructions make sure p = &dummyVar; is really executed and the debugger doesn't fool me.

Any idea?

• MathiasE: what is the crash about? you can find information about the crash by reading register SCB. See this link : Programming manual. You can first look at SHCSR register to see what kind of error that was caught by cpu.
• dpeng: The memory at 0xE000ED24 reads 0x00000000. See section 'Edit 2' in the post about the 'crash'.
• old_timer: is this a duplicate of the stackoverflow question?
• dpeng: The memory at 0xE000ED24 reads 0x00000000. See section 'Edit 2' in the post about the 'crash'.
• dpeng: I noticed in the backtrace that the WWDG (system window watchdog) interrupt handler was triggered. There is an alias from WWGD IRQ handler to the default handler (infinite loop).

Answer 1

QBS / Qt Creator was adding the -fPIC (position independent code) option to gcc command line in my back. Someone solved it here.