Lpc2000

Hi Kris

Your experiences here definitely agree with what I would expect.

When you modify the VIC mask to gate interrupts wou will get the 
sequence that leads to spurious interrupts.

Internal to the VIC, the interrupt is still "waiting", but is not 
enabled.  Therefore when you go reenable the mask for this interrupt 
it immediately executes. This explains why you don't lose any data.

The spurious interrupts should be benign, but chew some extra CPU. 
They should, IMHO, be used as an indicator that something is not 
right (ie. you should not really be having spurious interrupts in a 
finished product).

-- CHarles

--- In lpc2000@yahoogroups.com, "microbit" <microbit@c...> wrote:
> 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