Lpc2000

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