Lpc2000

Jaya, 

> If you read my original post carefully, you will realise that 
> I was talking about spurious interrupts, not nested 
> interrupts or interrupt lockouts.
> 
> The word "spurious" applied to interrupts means "lacking 
> authenticity or validity as to its origin".
> 
> The existence of an interrupt for which the system cannot 
> identify its source is deemed as a system failure, and hence 
> kernel "panics" in certified OSes.

I couldn't give a flying fig about Certified OSs.  The term "spurious"
in the Philips/ARM context is well defined.  You disable interrupts and
an ISR is entered nonetheless.  There are some other minor issues too.

> 
> --- In lpc2000@yahoogroups.com, "Paul Curtis" <plc@...> wrote:
>  > It is not just the VIC. ...
> 
> But we are talking about VIC, more specifically in the 
> context of ARM7TDMI.

I gave more references to other processor cores that also need to deal
with spurious interrupts.  You asked whether it was a VIC or core issue,
it is a core issue.  You just don't listen.

>  > Who cares?  The issue is well understood and the workaround easy.
> 
> Where spurious interrupt indicate system failure, any 
> workaround that relies on ignoring these interrupts is not a solution.

The workaround for this specific case (ISR entered, interrupts disabled)
can only occur in one way as far as I am aware.  This distinguishes a "I
didn't expect that, something bad has happened" case from a "I know
about that, I'll fix it" case.

--
Paul Curtis, Rowley Associates Ltd   http://www.rowley.co.uk 
CrossWorks for MSP430, ARM, AVR and now MAXQ processors