Hi,

I have a technical question in mind regarding the behavior of an Interrupt Service Routine (ISR) when its execution time exceeds than timer interval,

For example, When the timer ISR takes 1.5 milliseconds to execute while the timer interrupt is set for 1 millisecond intervals, I would like to understand the consequences of this scenario.

1. Does the ISR continue uninterrupted while the subsequent interrupt gets delayed?
2. Or, does the ISR not complete, and does the subsequent interrupt occur before it's finished?

My initial assumption is that the ISR won't finish and will be interrupted by the next interrupt, but I am looking confirmation and additional clarity on this matter.

If you think behavior is dependent on the specific microcontroller, I kindly request that you use your choice of microcontroller for explanation.

I appreciate any feedback

 

If you think behavior is dependent on the specific microcontroller...

It completely depends on the specific microcontroller, and in many cases how the interrupt controller is setup and your code.
In most cases the ISR will not be re-entered until the ISR exits and re-enables interrupts, but that's just a generalization.

Did you not like the answers you got on EEVBLOG?

 

It completely depends on the specific microcontroller, and in many cases how the interrupt controller is setup and your code.

I'm still confused and looking for clarification.

I mentioned choosing a microcontroller of your choice. What microcontroller do you typically use? Have you written code for a timer interrupt? If so, what are your expectations for its behavior in such a scenario?

 

What was unclear in my post?

 

It is far easier to learn material like this with a practical project. It has the additional benefit of providing a context for your questions which will reduce the frustration people trying to answer them feel when you tell them to fill in important details—which directly affect the answer—with arbitrary choices.

It can feel like you are taking advantage of the good will with which people approach offering assistance when you don’t seem willing to do your part in the exhange.

 

On a PIC 16F series, which has only one interrupt priority, no new interrupt will happen until the current one returns.

What happens in that case will depend on how your code is written. On the PIC, you have to explicitly clear the interrupt flag in your handler. Otherwise, the interrupt will occur again as soon as you return.

So, in your scenario, one of two things will happen depending on when you clear the interrupt flag. If you clear it before the next timer interrupt occurs, it will be set again by the timer and the handler will execute immediately again. If this happens on every timer interrupt, the processor will hang, doing nothing but handling the interrupts.

On the other hand, if you clear the interrupt flag right before returning, it will not be executed again and that timer interval will be missed.

So the real answer is don’t do it. Then it doesn’t matter. Relying on what actually happens in that case would be a bad idea. Interrupt handlers should always be as short as possible.

 

In general, nothing happens because you do not want to enable interrupts while still executing ISR, unless you enable prioritized interrupts.

It is just bad practice and poor design to make your ISR take too long.
In terms of ASM code, you don't want the ISR execute more than 20-100 instructions. So we are talking about 10 to 50μs depending on the speed of your CPU.

 

ARM microcontrollers will run the entire interrupt routine. When it complete, if there is another interrupt pending it will transfer to the pending interrupt routine without returning to the main routine. Only when all pending ISRs are completed will it return to the main routine.
Needless to say, writing interrupt routines which take longer to execute than the time between interrupts is a BAD idea.

 

Hi,

I have a technical question in mind regarding the behavior of an Interrupt Service Routine (ISR) when its execution time exceeds than timer interval,

For example, When the timer ISR takes 1.5 milliseconds to execute while the timer interrupt is set for 1 millisecond intervals, I would like to understand the consequences of this scenario.

1. Does the ISR continue uninterrupted while the subsequent interrupt gets delayed?
2. Or, does the ISR not complete, and does the subsequent interrupt occur before it's finished?

My initial assumption is that the ISR won't finish and will be interrupted by the next interrupt, but I am looking confirmation and additional clarity on this matter.

If you think behavior is dependent on the specific microcontroller, I kindly request that you use your choice of microcontroller for explanation.

I appreciate any feedback

Interrupts are called interrupts for a reason. In the embedded world, they interrupt. Meaning, if your interrupt takes longer than it's window, it will get interrupted and recalled. This leads to nesting of that interrupt and will die when stack-frame is exhausted.

You have to decide how you want to handle it. Be reentrant, or not.

Personally, if you can't get an interrupt done in a timely manner, your logic is wrong. If a task takes longer than an interrupt, then the interrupt should simply update a value, set a flag, do something small, and a slower, backer process works from that status.

 

First we must define: Too long. Yes, being longer than the critical time slice for any interrupt to the next is 'too long but I've got lots of devices I've designed and programmed where the main loop is simply for idle (does nothing). All I/O processing is handled in a interrupt or DMA context because it's better practice and good design to reduce useless context switches and flag based processing delays on critical signal paths.

 

First we must define: Too long. Yes, being longer than the critical time slice for any interrupt to the next is 'too long but I've got lots of devices I've designed and programmed where the main loop is simply for idle (does nothing). All I/O processing is handled in a interrupt or DMA context because it's better practice and good design to reduce useless context switches and flag based processing delays on critical signal paths.

I use that method.
main() is a setup routine which ends with a call to an assembler routine that does
:loop WFI
B loop

 

Meaning, if your interrupt takes longer than it's window, it will get interrupted and recalled.

Most architectures do not work this way... an interrupt of equal or lower-priority will not interrupt a running ISR.
The request is flagged and the new request will be handled when the current ISR finishes.

 

A example for PIC18 devices with vectored interrupts.

1. Interrupts set by the user as a high-priority interrupt have higher precedence of execution. High-priority
interrupts will override a low-priority request when:
1.1. A low-priority interrupt has been requested or its request is already pending.
1.2. A low and high-priority interrupt are triggered concurrently (i.e., on the same instruction cycle).
1.3. A low-priority interrupt was requested and the corresponding Interrupt Service Routine is currently
executing. In this case, the lower priority interrupt routine will be interrupted then complete executing
after the high-priority interrupt has been serviced.

2. Interrupts set by the user as low priority have a lower priority of execution and are preempted by any high-priority interrupt.

3. Interrupts defined with the same software priority cannot preempt or interrupt each other. Concurrent pending
interrupts with the same user priority are resolved using the natural order priority (when vectored interrupts are
enabled) or in the order the interrupt flag bits are polled in the ISR (when vectored interrupts are disabled)."

https://onlinedocs.microchip.com/ox...UID-2E6F3716-0151-4F82-8FC7-0117A2821C5D.html