Systick interrupt handler stopped being called

[JulienD]

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:

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

[waclawek.jan]

SysTick registers look OK.

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

JW

[JulienD]

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...

[waclawek.jan]

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

JW

[LCE]

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]

It finally happened!

[JulienD]

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 : 

[Karl Yamashita]

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.

[TDK]

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.