STM32WB55 jumps to SysTick_Handler when interrupts are enabled

[mstolpe_nloop]

The STM32WB55 it will jump to the SysTick_Handler interrupt handler routine after we have configured the clocks and the RTC and then enable the interrupts. I don't understand why this is happening. I have checked the following registers:

• SysTick->CTRL->CLKSOURCE is set to processor clock
• SysTick->CTRL->TICKINT is disabled
• SysTick->CTRL->ENABLE is active

Shouldn't the interrupt have been disabled by setting SysTick->CTRL->TICKINT to '0'?

[TDK]

When it's at SysTick_Handler, look at the VECTACTIVE field in SCB->ICSR to determine what interrupt the processor is in. Subtract 16 and compare to the values in IRQn_Type.

Note that systick gets enabled in HAL_RCC_ClockConfig.

 

Where are CLKSOURCE and ENABLE getting set but TICKINT is not?

[mstolpe_nloop]

The register had a hex value of 0xf so the final IRQ should be -1. When looking at rm0434 the position is not specified for CPU1. But the vector tables for CPU1 (CPU1 vector table) and CPU2 (CPU2 vector table) look pretty similar to me and it looks like this IRQ is associated with the systick timer. Am I right with this conclusion?

 

We're using low level driver functions to configure the microcontroller and we don't use the higher level functions which are provided by the STM SDK.

[TDK]

Yep, seems like it's SysTick interrupt.

Consider posting a minimal working example that exhibits the behavior. The chip isn't known to misbehave and call interrupts when they should not happen.

[mstolpe_nloop]

Unfortunately I can't show you a minimal example. The same code works and doesn't work under certain conditions. My guess is that this behavior is dependent on the power up sequence of the chip (VBAT and VDDA). We will try to test the behavior if we disconnect VBAT.

[STTwo-32]

Hello @mstolpe_nloop 

Any update?

Best Regards.

STTwo-32

[mstolpe_nloop]

Not yet. I hope I can post an update in the next two weeks.

[mstolpe_nloop]

I can't tell for sure what the problem was, but the problem was not the power sequencing. We have reworked the code for the clock configuration such that first the low speed clock domain is configured then the high speed clock domain. In the high speed clock domain we first setup the PLL and set the system clock to the PLL and afterwards the peripheral clocks are configured. This seems to have fixed the behavior we saw previously.