0
\$\begingroup\$

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?

\$\endgroup\$
7
  • \$\begingroup\$ 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. \$\endgroup\$
    – MathiasE
    Dec 22, 2016 at 14:47
  • \$\begingroup\$ The memory at 0xE000ED24 reads 0x00000000. See section 'Edit 2' in the post about the 'crash'. \$\endgroup\$
    – dpeng
    Dec 22, 2016 at 18:06
  • \$\begingroup\$ is this a duplicate of the stackoverflow question? \$\endgroup\$
    – old_timer
    Dec 22, 2016 at 20:09
  • \$\begingroup\$ The memory at 0xE000ED24 reads 0x00000000. See section 'Edit 2' in the post about the 'crash'. \$\endgroup\$
    – dpeng
    Dec 23, 2016 at 8:58
  • \$\begingroup\$ 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). \$\endgroup\$
    – dpeng
    Dec 23, 2016 at 9:05

1 Answer 1

1
\$\begingroup\$

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

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.