Lpc2000

Hi Charles,

> What you have to do in the default interrupt handler depends on the
> particular VIC. For instance, the ATMEL AT91xxx VIC has a spurious
> interrupt handler slot, with the documentation insisting that you
> must acknowledge the spurious interrupt (like you do with other
> interrupts) to clear the spurious interrupt condition. It would seem
> from what you write here that this is not required for the LPC21xx.
>
> Could it be that you're doing level sensitive interrupt handling and
> some "glitch" is propagated before the "real" interrupt? If so, then
> perhaps the "glitch" triggers a spurious interrupt and the "real"
> signal causes the intended activity.

In my tests there was only ONE interrupt enabled at that time - the UART0
TX/RX. (I dislike UARTs that don't have separate RX and TX vectors :-)
Loading new chars from the low level putch() style function, and then
enabling the RX/TX Interrupt on UART0 would cause default IRQ
exceptions on an asynchronous basis.
For example, running char output at a fixed "pattern" (RS232 flow wise)
would run fine.
Running my own SW (a Basic interpreter), would be OK too, but executing
very specific BASIC programs would cause Defaults.
Then, to make it more fun, the enabling/disabling of the INT mask by direct
write (ie. rewrite the register) vs. read-modify-write would affect this
behaviour
as well (more understandable from instruction level point of view).
The pipelining explanation and its interaction with the VIC seems very
plausible.
"Global" IRQ disable/enable "fixed" this.

The bizarre thing was that eg. merely lighting a LED when Default IRQ had
been
vectored BUT not doing anything else in the ISR clearly demonstrated that
despite
"spurious" defaults, the UART0 INT would still remain pending after leaving
the Default ISR,
as there were clearly _no_ chars missing in the UART0 TX output flow.

I ended up settling for the global IRQ protection, but wanted to know what
this really
was about. When I write code, I expect specific things - and if that doesn't
happen
I tend to want to know _why_ it doesn't work the way I perceived it should,
instead
of just changing methodology... I must be stubborn :-)

Cheers,
Kris