Skip to main content
Sietse
Associate III
December 8, 2016
Solved

HAL timer and ISR priority

  • December 8, 2016
  • 5 replies
  • 2777 views
Posted on December 08, 2016 at 11:38

Hello,

Using current HAL-software generated with cubemx on stmf4_discovery board.

I use TIM7 as an interrupt generating timer, set at say 100 msec.

In the ISR I do:

    i = HAL_GetTick();

    delayms(12);

    tt  = HAL_GetTick()-i;

where delayms is a busy waiting loop (normally our application code would go there).

And tt is a global int.

I would assume that tt would normally be something like 11, 12 or 13.

But it is always 0.

The (default) interrupt priority of TIM7 is much lower (higher number) than Systick, so why isn't the system tick not updated in that 12 msec?

Or am I missing something?

    This topic has been closed for replies.
    Best answer by Radek RIPA
    Posted on December 08, 2016 at 14:35

    Hello,

    The priority -1 on systick is taken in care only when the two interrupts have same settable priority.

    By default in CubeMX the Systick is set to 0.

    If you are using the CubeMX project please check the systick an tim7 priority in the project and the group priority option.

    0690X00000605nqQAA.png

    If the group priority do not have any bits for preemption priority then the interrupt cannot preempt second active interrupt.

    If you are not using the CubeMX please check the HAL_NVIC_SetPriorityGrouping and HAL_NVIC_SetPriority functions if they using correct priorities for systick and tim7 and correct group priority.

    Best regards

    Radek

    5 replies

    Walid FTITI_O
    Visitor II
    December 8, 2016
    Posted on December 08, 2016 at 12:37

    Hi

    Achterop.Sietse

    ,

    IT is the normal behaviour in your configuration status since the Systick can not preempt the Timer to make a delay. As a solution you can do one of the following scenario:

    • Make the Systick the highest priority ( if it make a problem in your application, tryto pause and resume it using the hal function)

    • When entering the ISR , inverse the priority of the systick and Timer

    • Use another timer to make the delay inside

      delay ms

    If the response is helpful , press the correct button down

    -Walid F-

    ST Renegade
    Associate
    December 8, 2016
    Posted on December 08, 2016 at 12:53

    Lets assume the systick really has higher priority than your timer. What is your delayms implementation? What is your core frequency? Try to increase the delay.

    A quick check, put an inifinite loop into the TIM ISR and put a breakpoint into the systick ISR. Observe whether systick ISR overrides the TIM or not...

    Renegade

    Sietse
    SietseAuthor
    Associate III
    December 8, 2016
    Posted on December 08, 2016 at 13:33

    I think I did follow the first scenario of Walid, and I just checked whether the Systick ISR is called when in the TIM ISR.

    It is NOT called at all.

    I did not change any priority, so the priority of Systick (-1) is much higher than that of TIM7 (55), so the systick should interrupt the TIM7 isr!

    So I still don't understand it.

    Radek RIPA
    Radek RIPABest answer
    ST Employee
    December 8, 2016
    Posted on December 08, 2016 at 14:35

    Hello,

    The priority -1 on systick is taken in care only when the two interrupts have same settable priority.

    By default in CubeMX the Systick is set to 0.

    If you are using the CubeMX project please check the systick an tim7 priority in the project and the group priority option.

    0690X00000605nqQAA.png

    If the group priority do not have any bits for preemption priority then the interrupt cannot preempt second active interrupt.

    If you are not using the CubeMX please check the HAL_NVIC_SetPriorityGrouping and HAL_NVIC_SetPriority functions if they using correct priorities for systick and tim7 and correct group priority.

    Best regards

    Radek

    Sietse
    SietseAuthor
    Associate III
    December 8, 2016
    Posted on December 08, 2016 at 15:21

    Thanks! Thats it.

    I wrongly mistook the index in the interrupttable as the priority:(

    It's working like a charm now. Thanks again.