Lpc2000

Jaya,

Since you keep asking, it doesn't take too much effort to find the 
following:

http://document.sharpsma.com/files/tec_errata_LH7A404-SMA03018A.pdf

This describes a similar issue with an ARM/VIC part where the default 
interrupt function is called in a spurious fashion. It may or may not 
be exactly the same problem, but it does tend to support the argument 
that the issue isn't unique to the Philips part.

My own interest is that some time ago we discovered this issue when 
stressing the UART. We found that very occasionally (after a couple of 
hours on a system with maybe 50k interrupts/second) the default 
interrupt handler would be called. We reported the problem to Philips 
(this was before there was either an app note or errata), who 
acknowledged the problem, and subsequently published the relevant 
information.

The interrupt is spurious in the sense that it happens and has no 
value. If you don't want to handle the source of the interrupt in the 
default interrupt handler, you don't have to. All you have to do is 
acknowledge the VIC that it's been seen (the usual write to 
VICVectAddr). If there is still an interrupt there, it will be handled 
as normal. Obviously, if the source of the interrupt has gone (as in 
the UART example where the received character will essentially 
overwrite the CTI interrupt source) there's no need for anything else. 
There's nothing been lost or not latched.

To be fair, this isn't totally clear from the Philips app note.

The bottom line though is that it's a known problem with a known 
solution, so why labour the point?

Brendan