STM32L1xx: changing interrupt priorities during interrupt - effects?

[Jon Green]

Posted on October 23, 2017 at 13:54

On an STM32L100 series MCU:

• Assume that initially, Systick priority is set below EXTI15_10
• During the EXTI15_10 ISR:
  • Systick occurs, but its interrupt is held because we're in a higher-prio interrupt;
  • I then change Systick prio in the ISR to higher than EXTI15_10;

...does that re-prioritised Systick interrupt immediately trigger as soon as I've changed the priority, or does it only trigger once I RTI from the EXTI15_10 ISR?

I'm guessing it would trigger immediately, but the RefMan and datasheet are silent.

Thanks in advance,

Jon

#stm32 #interrupts #nvic

[Tesla DeLorean]

Posted on October 23, 2017 at 16:37

For the NVIC the ARM documentation would be controlling.

You'd need the SysTick at a higher preemption level. Priority comes into play when you leave the Handler.

Changing things might be problematic if the other interrupt is already pending.

If high priority interrupts are blocking the rest of the processor operation you might want to rethink the strategy. Changing things on the fly gets you into metastability and inversion issues.

[Jon Green]

Posted on October 23, 2017 at 17:17

Thanks, Clive.

In this case, priority inversion is not an issue. The EXTI15_10 interrupt is triggered by an external signal, warning the MCU to close itself down.The idea is to minimise overall power consumption on the board, to buy time for another MCU to save away critical data. At this point, nothing in the mainline code will run henceforth, only interrupt code, and we'll never leave EXTI15_10.

The thinking is to pull clock/power from more or less everything (including timers) bar Systick and a couple of GPIOs we need to waggle during the shutdown, and drop into low-voltage, low-clock. Then we sit within the EXTI15_10 ISR, in a while(0 != countdown) { __asm { WFI } } loop, with the Systick ISR doing the countdown decrement to zero.

Once that loop has terminated, we set the GPIOs into their final state (-> 0), and it drops into a deeper low-power state compatible with keeping those GPIOs grounded.

Normally, Systick is a a relatively low priority interrupt. However, within the EXTI15_10 ISR, we need it to pre-empt us if this mechanism is to work, hence re-prioritising it to higher than EXTI15_10, in the expectation we'll get pre-empted.

However, if you're correct and the priority change doesn't take effect until the EXTI15_10 ISR exits - which it never will, under this plan - then we need to rethink. Perhaps have the final shutdown code actually in the Systick interrupt, once it's counted down to zero.

[Tesla DeLorean]

Posted on October 23, 2017 at 19:19

I would expect preemption levels to be honoured, the sub-priority is something that is handled when the BX LR to the special address causes the tail-chaining or unwinding to occur. You probably want to do a few tests, I would expect changing the NVIC on the fly would work 99.99% of the time, there's just a couple of corner cases that would concern me.

I'm assuming you have an SPL or register level implementation, the HAL needs the SysTick to preempt everything..

[Jon Green]

Posted on October 27, 2017 at 16:59

Yep, it's currently mostly register-level at present, but I'm trying to migrate the code to SPL as I work through it.

After a bit of thought, I'm going for a different strategy: stay in the original ISR, and use the RTC periodic timer as a WFE wakeup source instead of SysTick and WFI, which was in retrospect a slightly obtuse way to do it.

As a handy side-effect, after final shutdown of the subordinate hardware, I can change the RTC timer period to $HUGE, and sit in a WFE loop, waking up briefly just to kick IWDG.

Thanks for your help, Clive.