Skip to main content
Graduate
August 7, 2024
Question

Systick interrupt handler stopped being called

  • August 7, 2024
  • 4 replies
  • 3931 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.

    4 replies

    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

    JulienDAuthor
    Graduate
    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

     

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

    Super User
    August 8, 2024

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

    JW

    JulienDAuthor
    Graduate
    August 28, 2024

    It finally happened!

     

    JulienD_0-1724858060325.png

     

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

     

    Graduate 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?

    JulienDAuthor
    Graduate
    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

     

    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