All global variables set to non-initialized values after HAL_SYSTICK_Config()

[JustSomeGuy]

I am using the B-L072Z-LRWAN1 board. All global variables are their initialized values up until SystemClock_Config() executes HAL_RCC_OscConfig() which executes HAL_InitTick(). Once it reaches that point, all the global variables get filled with garbage values, and the program counter seems to stop executing the source code in main.c, and loops around a file called 0x1FF0017C.

The program did not always do this. it changed when I added code to debug the controller in LP run and stop mode. Here is the functions for entering LP run mode:

//put the controller in low-powered run mode
void enter_LPRun(void)
{
    /* 1. Each digital IP clock must be enabled or disabled by using the
                   RCC_APBxENR and RCC_AHBENR registers */
    RCC->APB1ENR |= RCC_APB1ENR_PWREN;
    RCC->APB1ENR |= RCC_APB1ENR_LPTIM1EN;
    RCC->APB2ENR |= RCC_APB2ENR_SPI1EN;
    /* 2. The frequency of the system clock must be decreased to not exceed the
          frequency of f_MSI range1. */
    // Reinitialize peripherals dependent on clock speed

    MX_LPTIM1_Init();
    MX_SPI1_Init();

    /* 3. The regulator is forced in low-power mode by software
          (LPRUN and LPSDSR bits set ) */
    //enable fast wake up for debugging
	PWR->CR |= PWR_CR_FWU;
    CLEAR_BIT(PWR->CR, PWR_CR_LPRUN); // Be sure LPRUN is cleared!
    HAL_PWREx_EnableLowPowerRunMode();
}

and in the while(1) loop, under a conditional, here is the code to put the controller in stop mode.

		  //enable debugging in stop mode
		  SET_BIT(DBGMCU->CR, DBGMCU_CR_DBG_STOP);
		  //this bit has to be cleared before entering stop mode
		  __HAL_PWR_CLEAR_FLAG(PWR_FLAG_WU);
		  //enter STOP mode, wait for interrupt
		  HAL_PWR_EnterSTOPMode(PWR_LOWPOWERREGULATOR_ON, PWR_STOPENTRY_WFI);

Attached is my ioc file. Let me know if you need anything else.

edit: more precisely, the behaviour happens on the command NVIC_SetPriority() here (ticks = 131):

__STATIC_INLINE uint32_t SysTick_Config(uint32_t ticks)
{
  if ((ticks - 1UL) > SysTick_LOAD_RELOAD_Msk)
  {
    return (1UL);                                                   /* Reload value impossible */
  }

  SysTick->LOAD  = (uint32_t)(ticks - 1UL);                         /* set reload register */
  NVIC_SetPriority (SysTick_IRQn, (1UL << __NVIC_PRIO_BITS) - 1UL); /* set Priority for Systick Interrupt */
  SysTick->VAL   = 0UL;                                             /* Load the SysTick Counter Value */
  SysTick->CTRL  = SysTick_CTRL_CLKSOURCE_Msk |
                   SysTick_CTRL_TICKINT_Msk   |
                   SysTick_CTRL_ENABLE_Msk;                         /* Enable SysTick IRQ and SysTick Timer */
  return (0UL);                                                     /* Function successful */
}

[Tesla DeLorean]

It's about the Interrupt and Sleeping, not specifically the SysTick initialization.

Realistically you shouldn't expect the processor to be viable for debugging across the powering down of those interfaces and clocks.

[JustSomeGuy]

The thing is that I am getting the same behaviour when I am debugging vs when I am not. So far the debugging in low-power modes seems to be working fine. Can please you expand a bit on what you mean by "It's about the Interrupt and Sleeping"?

[Tesla DeLorean]

Well, that the problem is with it interrupting, not you initializing a particular function.

So how the vector table is mapped, where it's going.

>>.. a file called 0x1FF0017C

A file? You mean it's executing code from the System ROM?

How's it getting there? BOOT0 pin setting/state?

The STM32L072CZ is a CM0+ so there's a SCB->VTOR that can be set in SystemInit()

Exiting STANDBY is basically a RESET

The debugger is invasive, and the logic behind it can't turn-off and remain viable. Best to output telemetry to understand the internal states, rather than probe externally in hopes of understanding what's going on with the cat inside the box..

[Shirley.Ye]

Hello,

seems it is an interrupt issue.

when the systick is initialized, the PC should jumps to the SysTick_Handler periodically if the VTOR is correctly set. 

In your case the pc loops around 0x1FF0017C seems jumps to the system memory which contains the bootloader.

you can check the SCB->VTOR first.