Skip to main content
JulienD
Associate III
August 7, 2024
Question

Systick interrupt handler stopped being called

  • August 7, 2024
  • 13 replies
  • 6811 views

Hello

 

STM32G0B1

 

For some obscure reason, sometimes the systick handler function is not called anymore.

I mean, it works for some time then it does not work anymore. It looks like it is more likely to happen when I'm debugging but I have no factual information to provide for this assumption.

Here's the content of the systick registers:

JulienD_0-1723030099147.png

 

The IT is activated. 

VTOR is at adress 0. I don't have any reason to change this.

What can I do to have a clue to understand what happen?

 

Thanks

Julien

This topic has been closed for replies.

13 replies

waclawek.jan
Super User
August 7, 2024

SysTick registers look OK.

Maybe your program is stuck in an interrupt? Perhaps in a Cube/HAL delay function?

JW

JulienD
JulienDAuthor
Associate III
August 8, 2024

Ok, Thanks. It took some time to reproduce.

As you can see on this new screenshot : 

- There's a breakpoint in the systick interrupt. after some time, the system never stop on it (and the related code is not called, so it's not a breakpoint issue).

- I paused the system, it is not in an interrupt routine

- systick registers are same as in previous post.

- If I continue debug and pause it again, the tick counter value has changed.

 

I feel like in the dark side...

 

JulienD_0-1723127322045.png

 

Karl Yamashita
Principal
August 30, 2024

You're calling 5 functions inside the interrupt. 1 or more of those functions are probably blocking. Without seeing those code, no telling what you're doing.

 

Instead, save the tick value and set a flag and exit the interrupt. Then in main while loop, check flag and then pass the saved value to those functions.

If a reply has proven helpful, click on Accept as Solution so that it'll show at top of the post.CAN Jammer an open source CAN bus hacking toolCANableV3 Open Source
waclawek.jan
Super User
August 8, 2024

Once you are at it, show also the SCB registers' content.

JW

JulienD
JulienDAuthor
Associate III
August 28, 2024

It finally happened!

 

JulienD_0-1724858060325.png

 

TDK
August 30, 2024

VECTACTIVE of 0x1B indicates it is in the DMA1_Ch4_7_DMA2_Ch1_5_DMAMUX1_OVR interrupt. Likely this is blocking and preventing other interrupts from happening.

As @LCE mentioned, ensure systick has the highest (numerically lowest) priority if you want it to take precedence.

Also agreed it's generally bad form to call so many functions within the interrupt, especially the systick interrupt. This isn't purely for style reasons. If things accessed in these functions are also accessed in the main thread, this can lead to race conditions and other bad behavior. You aren't showing too much code here so it's anyone's guess as to what is happening. Surely it is a code bug though, not a silicon failure.

 

"If you feel a post has answered your question, please click ""Accept as Solution""."
LCE
Principal II
August 9, 2024

Lots of stuff happening in your Systick_handler, maybe you should use another timer for that stuff?

In case of doubt concerning the SysTick, I always build a quick 1ms-timer with interrupt which just counts upwards, same as the SysTick.

And does the Systick interrupt have the highest priority?

JulienD
JulienDAuthor
Associate III
August 28, 2024

1- Not that much happens in systick_handler in fact, calls are more or less setting a boolean and sometime a 10µs call...

2- Yes : 

 

JulienD_1-1724858372655.png

 

waclawek.jan
Super User
September 6, 2024

Nonzero VECTACTIVE does not mean that you are executing the code *you've written* for that particular interrupt. It means, that the processor entered that interrupt and never exited or never entered a higher priority interrupt. For example, you might have exited execution of that code in an incorrect way, by manipulating (or corrupting) the stack.

JW