STM32WB55 jumps to SysTick_Handler when interrupts are enabled
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2025-02-27 12:54 AM
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'?
- Labels:
-
Other hardware
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2025-02-27 4:20 AM
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2025-02-27 7:47 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2025-02-28 6:35 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2025-03-05 7:23 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2025-03-25 3:10 AM
Hello @mstolpe_nloop
Any update?
Best Regards.
STTwo-32
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2025-03-25 8:18 AM
Not yet. I hope I can post an update in the next two weeks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2025-04-25 7:19 AM
Disconnecting VBAT didn't change the behavior but other than that we didn't test anything yet.
