Higher priority timer will preempt lower priority external interrupt, but will not preempt a lower priority timer.

[Charles P]

EDIT: Hello, everyone. My code issue seems to have resolved itself after much changing, but I never did find out what was happening. My real question was answered: There are no likely circumstances that a higher-priority interrupt should not pre-empt a lower priority interrupt, even if they are both timer interrupts. Thank you all for your help. I'll leave the original thread alone.

I have a priority 2 timer TIM1, a priority 6 timer TIM4, and priority 5 EXTI9_5.

TIM1 occurs every 1 ms. It clears the interrupt then increments uwTick then returns.

EXTI9_5 operates when I push a button. It is a while(1) loop which does not clear the interrupt so it just locks up.

TIM4 occurs every 30 seconds. It is a while(1) loop so it just locks up. The following scenario occurs regardless of whether or not the interrupt is cleared before the while(1) loop.

If I debug and press the button before the 30 second mark, I can see that TIM1 continues to operate. However, if I debug and simply wait for TIM4 to interrupt (and I debug to verify that it is interrupting), then TIM1 no longer interrupts, even though it has the higher preemption (lower number, higher priority).

How can I get TIM1 to preempt TIM4? Thanks.

[waclawek.jan]

Which STM32? Do you use Cube? Have you tried without the debugger?

JW

[Charles P]

(deleted and moved to reply directly to waclawek.jan)

[Charles P]

STM32H7A3ZIT6

I have tried without the debugger and had the same result.

Thank you for responding to my request for help.

[MM..1]

Where loop your code after 30s? In Tim4 while or other fault.

[Tesla DeLorean]

Infinite loops, or any heavy work in interrupts or callbacks is generally problematic.

The Cortex-M7 should allow you to model how the NVIC groups, prioritizes and services interrupt and system handlers.

Much of the timeouts/delays in HAL are predicated on SysTick (or the primary time base) actually preempting everything.

Would perhaps focus on the Priority Grouping settings.

[waclawek.jan]

(waclawek.jan has not received your direct reply)

JW

[Pavel A.]

It looks like you haven't actually enabled interrupt preemption (by setting the "priority grouping").

Is your button EXTI interrupt programmed for falling or raising front or both?

[Charles P]

Hi, MM. Thank you for responding. This code is designed to test priority of interrupts, so it is designed that if TIM4 is entered, the code never leaves it unless a higher priority interrupt occurs. It should be that if I press the button before TIM4 occurs (before 30 seconds) that EXTI interrupt occurs and TIM1 interrupt continues to occur. This is the case. However, whenever TIM4 enters, TIM1 stops. But this should NOT be the case because TIM1 has a higher priority. I am wondering why this might be happening. Do you have any ideas or suggestions? Thanks.

[Charles P]

Hi, TD. Thank you for responding. This code is designed to test priority of interrupts, so the purpose of the while loop is to lock up the TIM4 interrupt and verify that TIM1 continues to fire. However, that is not happening. If TIM4 enters it's while(1) loop, TIM4 never fires again. That seems to be contrary to what I expect. I am wondering why this might be happening.

Thank you for the suggestion to focus on the priority grouping settings, also. That's specifically what I'm trying to do here with this test code. I'm trying to figure out why TIM1 does not fire if TIM4 fires. TIM1 has a higher priority (lower number) so it should not stop operating just because TIM4 is in a while(1) loop. Unfortunately, that seems to be what is happening.

Do you have any further suggestions to try? Thanks.