More on spurious interrupts...
2006-03-17 by brendanmurphy37
There's been a degree of noise recently on the issue of spurious
interrupts, the importance of which has been blown out of all
proportion. Various claims have been thrown into the mix, which
might lead one to believe that there's some sort of serious,
undocumented and underlying flaw in the LPC2000. It's my belief,
based on the information available and direct experience of the
issue, that (1) there is an issue with spurious interrupts; (2) it
can be a problem; and (3), the fix is simple.
The issue is that in certain conditions the VIC doesn't provide the
correct vector address (in VICVectAddr) when handling vectored
interrupts: it provides the default vector address (VICDefVectAddr)
instead. This is a very rare occurrence. Mentioning this rarity is
not to indicate it can be ignored, but is a warning that you're
unlikely to see it in normal testing. Whether this issue is specific
to the Philips parts, or is a general ARM issue (both core and VIC
are ARM designs) is a moot point: the behaviour exists.
The problem is that the default initialisation of the VICDefVectAddr
is zero. Hence, if this condition happens, the default behaviour is
for the processor to jump to zero. On some systems this is
completely benign; on others it could be catastrophic.
The fix is simple, and as already been pointed out, good programming
practice in any case: you need to supply a default interrupt handler
even if strictly speaking your system doesn't otherwise need one.
This is the one we use:
void default_interrupt_handler(void)
{
return;
}
The VIC needs to be initialised with something like:
VICDefVectAddr = (unsigned int) default_interrupt_handler;
That's about it. One final minor point is that the above assumes
that the assembler code that dispatches the `C' interrupt handler,
and to which it returns, writes to VICVectAddr after the function
returns. If not, you'll need to add something like the following to
the interrupt handler:
VICVectAddr = 0xff;
The only disadvantages that I can see to this whole issue is that
(1) you have to be aware of it (2) you have to provide a fix (which
can be very simple though) and (3) there is an overhead in handling
the spurious interrupt (it happens so rarely though this can be
discounted).
All of this is well documented, by the way.
There's no case where interrupts are lost or the system will get
locked or fail in some mysterious way. If anyone (including and
especially Philips) has information or hard evidence to the
contrary, I'd be very interested to hear it, as I'm sure others
would.
Further information for those interested:
There is an app note from Philips that shows how you can handle the
source of the interrupt in your default interrupt handler. You can
obviously do this, although you are faced with the issue of
identifying the source. To my mind this approach is somewhat
misguided: it's unnecessarily complex, and it will be difficult to
test (due to the very sporadic nature of the problem arising). I
think it's better to just do nothing in the default handler: the
peripheral's interrupt will remain asserted and the correct vectored
interrupt will be entered subsequently (maybe not immediately if a
higher priority interrupt has happened in the meantime).
As a note to Jaya: your concern over the UART CTI interrupt
being "ill conditioned" or "not latched" is misplaced. The statement
in the app note about a character being received clearing the CTI
interrupt is simply restating the UART description of the UART
Interrupt Identification Register (IIR): it will always happen,
regardless of whether or not there's a spurious interrupt (or even a
VIC for that matter). There's no suggestion that the interrupt isn't
latched and remain so until the IIR is read. My own previous
reference to this as "overwriting" may have been clumsy or
imprecise, but hardly "silly". You are of course entitled to your
opinion.
Brendan