Lpc2000

--- In lpc2000@yahoogroups.com, "microbit" <microbit@c...> wrote:
> > > 1) VIC decides there is an interrupt and sends the NIRQ signal 
to the 
> > > core.
> > > 2) Core latches the NIRQ state.
> > > 3) Processing continues for a few cycles due to pipelining.
> > > 4) Core loads IRQ address from VIC.
> > 
> > So, you're saying the VIC is BAD--Broken As Designed.  There 
should
> > be a latch *in the CPU core* that holds the vector when the NIRQ
> > is asserted and an acknowledge to clear the VIC.
> > 
> > Yes, yes, I know, one can live with this, but it's more in the 
realm
> > of "documented bugs are features" rather than something one would
> > actually want to work this way.
> 
> I agree here David.
> When I banged my head on a brick wall with this, determined to find 
what
> was wrong, my final conclusion was that I considered it to be a 
flaw in the VIC
> as far as I'm concerned. (as naively posted by me some time ago :-)
> 
> A "bug" of course would constitute a silicon problem where eg. 
another ARM part
> doesn't do this.
> I've only worked with LPC2000 so far, I don't know if macrocells 
from different
> vendors behave the same, I presume someone would have said so by 
now if that 
> was the case,  ....so I take credit for word of the more seasoned 
die-hard ARM-ers here :-)
> 
> I was still puzzled to find that in my case letting it run where 
the default_IRQ just returns
> from the ISR, that I wasn't missing processing in my actual ISRs 
that were supposed to have been
> vectored. This implies to me that a branched default IRQ that 
simply returns leaves the actual
> vectored interrupt still pending ......
> 
> Confused ?
> You won't be after this episode of SOAP... :-)

The spurious interrupt thing also happens on other ARM devices and is 
reasonably well known in ARM land.

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.

-- CHarles