lost interrupts and/or priority inversion

[EtherJones]

Can someone please review this and offer opinion on whether my understanding is correct?

First I need to set up the problem before I can ask the question:

1) MC9S08DZ60

2) two active interrupts, call them Int1 and Int2, one occurring approximately 10 times faster than the other (Int1 faster than Int2)

3) Int1 is serviced by ISR1, and Int2 is serviced by ISR2

Question:  Are the following statements true?

ISR2 worst-case execution time must never exceed the Int1 period, or else Int1 interrupts will be lost.   This is because more than one Int1 will occur while ISR2 is executing.  The first Int1 will be pending (waiting for ISR2 to complete), but there is no provision in this chip to queue the second one - it will be effectively lost.

This problem could be solved by coding ISR2 to enable interrupts at the beginning.  But the problem with this is that not only would Int1 be allowed to interrupt, but also any other slower or lower-priority interrupt - resulting in priority inversion.

[thisobj]

One problem to be watchful for with nested interrupts is stack overflow. This is especially critical if you are running an OS in which each task has a dedicated stack space. An easy method to monitor for this condition is to initialize the stack space(s) to a known value, run the program with the debugger and then display the stack space to view worst-case usage. A more thorough technique is to include debug code that dynamically monitors usage.

[rocco]

Hi, Ether:

Yes, both statements are true. But it should not be a big deal.

The nested-interrupt approach may be a little more complicated, but should work. I would not worry about a lower priority interrupt, as long as its ISR was short.

Also, you could disable lower priority interrupts prior to re-enabling interrupts in the ISR, and re-enable them prior to exiting the ISR (after disabling interrupts globally again, to prevent them from nesting).

But my approach is to keep all ISRs under 5 microseconds (a somewhat arbitrary number, based on running the SCI at 500 kBaud). If additional processing is necessary, I schedule a subroutine do execute after the ISR exits. I can assign priorities to those subroutines, and code them to process the data from multiple interrupts, if need be (like parsing an entire line of data from the SCI).

[EtherJones]

Also, you could disable lower priority interrupts prior to re-enabling interrupts in the ISR, and re-enable them prior to exiting the ISR (after disabling interrupts globally again, to prevent them from nesting).

Bingo.  This is what I was looking for.  I want to be able to make an ISR interruptable, but only by higher-priority interrupts.  This sounds like a straightforward and bulletproof way to do it.  My only concern is this: I assume that if one of these disabled interrupts occurs while it is disabled, then the interrupt flag will still be set, and it will interrupt as soon as the interrupt is re-enabled.  In other words, I won't drop interrupts this way.  Correct?

[bigmac]

Hello Ester,

Another possibility -

Before exiting the ISR in which you have disabled lower priority interrupts, you might test the flag for the lower priority event, and if set, JMP straight to its ISR, without the need to exit and re-enter the interrupt process.  This can give some reduction of latency for the lower priority event because there is not the overhead for the exit and entry process.  In the second ISR, interrupts can be re-enabled within the same process in which the flag is cleared.

Regards,

Mac

[peg]

Hi Ether,

Yes the flag will remain set and the ISR will occur as soon as you enable it.

You just have to be careful the disabled ISR only gets triggered once while it is disabled.

Regards

Peg