AnsweredAssumed Answered

Interrupts at the same priority when active together do not execute back to back

Question asked by Ian Holmes on Apr 21, 2020
Latest reply on Apr 23, 2020 by Ian Holmes

I have a design where timers 16 and 32 have their capture inputs enabled and each generates an interrupt at level 0.

In each ISR the captured value is copied to a register, a flag set and the ISR completes. There is one for each timer.

When I run fast pulses (600us between) I noticed that one interrupt did not seem to fire, and so I have debugged the application using the Keil MDK IDE and ULINK2.

When the first ISR is entered the NVIC shows VECTACTIVE 0x22 and VECTPENDING 0x20 as expected, as both timers are connected to the same pulse generator for testing.


When I step through the code, and after removing the pulse counter, I watch the VECTACTIVE return to 0x00 at the end of the first ISR and I see that the VECTPENDING remains as 0x20 showing the first interrupt is handled and cleared and the second is waiting processing. No other interrupts are active in the system which I can read from AIRC.


What happens next confuses me. The code execution returns to the normal code and I step over several 100 lines of C code before I get bored - and there is no call to the second ISR and it remains pending. So I set a break point in the 2nd interrupt and allow the application to run and the code breaks into the ISR and on exit the pending second interrupt is cleared.


The then use two breakpoints and the system timer to measure the execution times to the two ISR, and the time from the end of the first to the start of the second. Both ISR typically execute in less than 1us, but sometimes as much as 5us which I do not understand. The time from int 1 ending to int 2 starting is also variable, between 15us and 56us.


My questions are : Why does int 2 not follow int 1 immediately as it is pending, and what is it which triggers the handling of it later?


It may be that it is not possible to use the system timer to measure the times as I have noted above (for example if it does not freeze during a break) - however the code should execute in the correct order, and that implies that the interrupts do not follow in sequence. I assume I'm missing something but I can't see it for looking!