How do you test your interrupt handling module?

Question

I've got an interrupt handling module which controls the interrupt controller hardware on an embedded processor. Now I want to add more tests to it. Currently, the tests only tests if nesting of interrupts works by making two software interrupts from within an ISR, one with low priority and one with high priority. How can I test this module further?

Answer 1

I'm not an embedded developer, so I don't know if this is possible, but how about decoupling the code that handles the interrupts from the callback-registration mechanism? This would allow you to write simulator code fireing interrupt-events as you like it...

Answer 2

I suggest that you try to create other stimuli as well.

Often, also hardware interrupts can be triggered by software (automatic testing) or the debugger by setting a flag. Or as an interrupt via I/O. Or a timer interrupt. Or you can just set the interrupt bit in an interrupt controller via the debugger while you are single stepping.

You can add some runtime checks on things which are not supposed to happen. Sometimes I elect to set output pins to monitor externally (nice if you have an oscilloscope or logic analyser...)

low_prio_isr(void)
{
    LOW_PRIO_ISR=1;
    if (1 == HIGH_PRIO_ISR)
    { this may never happen. dummy statement to allow breakpoint in debugger }

}

high_prio_isr(void)
{
    HIGH_PRIO_ISR=1
}

The disadvantage of the software interrupt is that the moment is fixed; always the same instruction. I believe you would like to see evidence that it always works; deadlock free.

For interrupt service routines I find code reviews very valuable. In the end you can only test the situations you've imagined and at some point the effort of testing will be very high. ISRs are notoriously difficult to debug.

I think it is useful to provide tests for the following: - isr is not interrupted for lower priority interrupt - isr is not interrupted for same priority interrupt - isr is interrupted for higher priority interrupt - maximum nesting count within stack limitations.

Some of your tests may stay in the code as instrumentation (so you can monitor for instance maximum nesting level.

Oh, and one more thing: I've generally managed to keep ISRs so short that I can refrain from nesting.... if you can this will gain you additional simplicity and more performance.

[EDIT] Of course, ISRs need to be tested on hardware in system too. Apart from the bit-by-bit, step-by-step approach you may want to prove: - stability of system at maximum interrupt load (preferably several times the predicted maximum load; if your 115kbps serial driver can also handle 2MBps you'll be ok!) - correct moment of enabling / disabling isr, especially if system also enters a sleep mode - # of interrupts. Can be surprising if you add mechanical switches, mechanical rotary (hundreds of break/contact moments before reaching steady situation)

Answer 3

I recommend real-hardware testing. Interrupt handling is inherently random and unpredictable.

Use a signal generator and feed a square wave into the appropriate interrupt pin. Use multiple generators (or one with multiple outputs) to test multiple IRQ lines and verify priority handling.

Experiment with dialing the frequency up & down on the signal generators (vary the rates between them), and see what happens. Have lots of diagnostic code to verify the state of the interrupt controller in the various states.

Alternative: If your platform has timers that can trigger interrupts, you can use them instead of external hardware.

Answer 4

For stuff like this I highly recommend something like the SPIN model checker. You wind up testing the algorithm, not the code, but the testing is exhaustive. Back in the day, I found a bug in gdb using this technique.