Lpc2000

> > 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... :-)

B rgds

Kris