What happens if a isr is too long.

leverett wrote on Friday, May 04, 2012:

Hello, I am using FreeRTOS on a PIC32. I have an ISR that “I think” works fine. It has an interrupt priority above the maximum set for the RTOS and disables interrupts on entry, enables on exit. I therefore believe it can be written in C with no wrapper.

In the documentation I read that the ISR should be kept as short as possible. I understand and I am doing that.

However, what if I didn’t? What will happen if the ISR gets too long. Suppose it takes longer than the RTOS tick. Since interrupts are disabled, the tick cannot stop it can it? Will the scheduler simply wait until the ISR finishes or will there be some nasty consequence?

I understand this is a stupid question because one would never have an ISR that long but I’m just trying to understand how the RTOS functions.


nathanwiebe wrote on Friday, May 04, 2012:

Even a short ISR has the possibility of being in-process when other ISRs become signalled.  What happens in a nested interrupt controller is that lower priority (or same priority) interrupts set a hardware flag in the processor that remains set until the you service that particular interrupt.  If the tick timer fires, it will just run that ISR when yours is done.  The same is true of an ISR that is within the acceptable range to make kernel calls - the tick ISR has to wait.  If, on the other hand, your higher priority interrupt fires while the MCU is in the tick ISR, it will jump into yours and come back to the tick ISR later.  If your ISR is too slow, then it will just mean other interrupts have bad latency (time from event to ISR action).  Your worst case latency on a given ISR is the sum of the worst case run times of the longest ISR in each priority level you are using.  In the case of the tick, you would have to have a really slow ISR to overlap two ticks events, thus potentially dropping a tick and throwing out the OS’s delays.

richard_damon wrote on Friday, May 04, 2012:

An ISR taking too long won’t “break” the RTOS in the sense of it crashing or something like that. It may well “break” your program in that it no longer meets your real time requirements. Interrupts taking so long that you might miss a timer tick interrupt will cause your program’s sense of time to be disturbed, more time has really passed than the program knows about.

Interrupts, by their nature are limited in their flexability to schedule their control routines, They may have a nesting, but they can’t “defer” and then resume like a task. Tasks on the other hand are very flexible in execution control.

When NOT using an OS, the ISR needs to do everything needed to service the device, as it has no other way to get something to execute. When using an OS that isn’t an RTOS, it might be able to hand off “low priority” operations to a task, but the hallmark of a RTOS is that you can setup a “real time” task to get high priority work done on time.
With an RTOS, you typically do very little in the ISR, normally not more than (maybe) grabbing the data and clearing the interrupt, and any more complicated work is left for a task. Think of it as the ISR handles things that need to be done in microseconds, while the task handles stuff that is more on the order of milliseconds, or so. There isn’t THAT much of a cost in time to transition to the task to process, as if that task is the highest priority available, it should run as soon as the ISR exits.

For this to work this way, the Interrupt should NOT be “above the max set for FreeRTOS”, as such an interrupt WILL need to interact with FreeRTOS.  The only real reason I can think of to have an interrupt above the FreeRTOS max level is something that handles activity that REALLY needs microsecond level response or you get failure, so the interrupt can’t be temporarily masked for some FreeRTOS operations in critical sections. FreeRTOS has been designed with the goal of these periods being as short as possible (and of a knowable limited length). Having this type of routine around normally requires very definite care and planning.