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]

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

[TDK]

I suspect the two screenshots were taken at different states. They weren't posted at the same time. It's low probability that the IRQ failed to exit yet the stack information stayed correct. Could be wrong through, we're only getting glimpses into what is happening. In any case, that's the issue.

[Tesla DeLorean]

Break-pointing and single-stepping a real time system is never going to provide an accurate understanding of the dynamics. Humans run too slowly.

Instrumentation would probably work better, might add some drag, but it won't be grinding gears to the same degree.

An interrupt will keep re-entering, via tail-chaining, if the cause isn't cleared, or gets reasserted.

Priority and Preemption will determine what can run from where. The CM0(+) have less options than other cores.

Use TIM->CNT's rather than software interrupts counting off time where you're deep in interrupts and callbacks, and potentially blocking other interrupts.

With "Systick interrupt handler stopped being called", the MCU clearly thinks it has better, more pressing things to be attending too. Review the mechanics, carefully.

Key-hole debugging via screen-shots, is not fun for observers..

[TDK]

Do you do any jumping in this application? Jump to bootloader or main application? Could be that you jumped from within that interrupt. That would explain what you're showing us.