Lpc2000

Brendan,

Yet again your post contradicts many findings by different people in this 
forum.  Furthermore it is not consistent with explanations in both AN10414 
and PL190TRM.

1/  The issue you vaguely refer to as "certain conditions does not provide 
correct vector address" has been explained precisely in AN10414.  What is 
missing or not the underlying cause.

When the VIC raises the interrupt, it determines the source of the 
interrupt and loads this into the call vector.  [Quick experimentation 
suggests it does this correctly.]

However if this interrupt was disabled (in the pipeline) after it was 
raised, when the ISR reads this call vector, VIC returns the default vector 
instead.

It does not appear that call vector was corrupted and all indications are 
that it is still there.  It is not clear why the VIC chose not to return 
the call vector -- I can only guess it was gated with interrupt enable bit 
as a shortcut.

The solution to avoiding spurious interrupts (and not working around by the 
default ISR polling all possible interrupt sources as recommended in 
AN10414) involves determining why the VIC returned the default vector.

[Note that this has little to do with the ARM7TDMI interface with VIC as 
this problem is generic to all pipelined architectures.]

2/  According to AN10414 and PL190TMR, your fix that involves ignoring the 
interrupt, and returning from interrupt by just writing 0xff to the call 
vector register WILL NOT WORK.

AN10414 states:

>In this handler, the following should be done:
>1. Find the source of the interrupt (if there are multiple interrupt ources).
>2. Clear the interrupt source (optional as shown in the UART case).
>3. Update the VIC by writing to the VIC Vector Address Register.

PL190TM states:

>You must use this register as follows:
>• the ISR reads the VICVectAddr Register when an IRQ interrupt is generated
>• at the end of the ISR, the VICVectAddr Register is written to, to update 
>the priority hardware.
>
>Reading from or writing to the register at other times can cause incorrect 
>operation.

3/  The solution outlined in AN10414 IMO creates more problems and imposes 
additional (difficult) constraints relating to mutual exclusion on ALL 
ISRs, not just those relating to vectored interrupts.

[I am in the processing of documenting a solution to the VIC spurious 
interrupt problem on LPC2294.  It is based on PREVENTING, not HANDLING 
spurious interrupts.  There are a issues still outstanding.]

Based on what I have been working with over the last week, I know that, if 
you do not appreciate the problem correctly, you are in be in for a lot of 
surprises when you use the LPC in a system where there are lots of random 
and and successive interrupts from the one source, for example an 
accelerometer.

Good luck.

Jaya

--- In lpc2000@yahoogroups.com, "brendanmurphy37" <brendan.murphy@...> wrote:
 >
 > There's been a degree of noise recently on the issue of spurious
 > interrupts, the importance of which has been blown out of all
 > proportion. Various claims have been thrown into the mix, which
 > might lead one to believe that there's some sort of serious,
 > undocumented and underlying flaw in the LPC2000. It's my belief,
 > based on the information available and direct experience of the
 > issue, that (1) there is an issue with spurious interrupts; (2) it
 > can be a problem; and (3), the fix is simple.
 >
 > The issue is that in certain conditions the VIC doesn't provide the
 > correct vector address (in VICVectAddr) when handling vectored
 > interrupts: it provides the default vector address (VICDefVectAddr)
 > instead. This is a very rare occurrence. Mentioning this rarity is
 > not to indicate it can be ignored, but is a warning that you're
 > unlikely to see it in normal testing.

I would not call this a rare occurrence given the number of people in this 
forum who raised spurious interrupt problems resulting in Philips releasing 
an application note early this year.

 > Whether this issue is specific
 > to the Philips parts, or is a general ARM issue (both core and VIC
 > are ARM designs) is a moot point: the behaviour exists.

It is not a moot point for those who cannot tolerate spurious interrupts. 
They wish to know if VIC generates spurious interrupts in other ARM7TDMI 
variants as claimed in AN10414.

[This is the my reason for looking into this problem.]

 > The problem is that the default initialisation of the VICDefVectAddr
 > is zero. Hence, if this condition happens, the default behaviour is
 > for the processor to jump to zero. On some systems this is
 > completely benign; on others it could be catastrophic.
 >
 > The fix is simple, and as already been pointed out, good programming
 > practice in any case: you need to supply a default interrupt handler
 > even if strictly speaking your system doesn't otherwise need one.

See above why this simple solution is not a solution.

 > This is the one we use:
 >
 > void  default_interrupt_handler(void)
 > {
 >       return;
 > }
 >
 > The VIC needs to be initialised with something like:
 >
 > VICDefVectAddr = (unsigned int) default_interrupt_handler;
 >
 > That's about it.

When spurious interrupts are involved, ignorance is no bliss.

 > One final minor point is that the above assumes
 > that the assembler code that dispatches the `C' interrupt handler,
 > and to which it returns, writes to VICVectAddr after the function
 > returns. If not, you'll need to add something like the following to
 > the interrupt handler:
 >
 > VICVectAddr = 0xff;
 >
 > The only disadvantages that I can see to this whole issue is that
 > (1) you have to be aware of it (2) you have to provide a fix (which
 > can be very simple though) and (3) there is an overhead in handling
 > the spurious interrupt (it happens so rarely though this can be
 > discounted).
 >
 > All of this is well documented, by the way.
 >
 > There's no case where interrupts are lost or the system will get
 > locked or fail in some mysterious way. If anyone (including and
 > especially Philips)  has information or hard evidence to the
 > contrary, I'd be very interested to hear it, as I'm sure others
 > would.

If you ignore the interrupts as you propose, you will lose interrupts for 
sure.  Not only that, you could end up in live-lock situation.

 > Further information for those interested:
 >
 > There is an app note from Philips that shows how you can handle the
 > source of the interrupt in your default interrupt handler. You can
 > obviously do this, although you are faced with the issue of
 > identifying the source. To my mind this approach is somewhat
 > misguided: it's unnecessarily complex, and it will be difficult to
 > test (due to the very sporadic nature of the problem arising). I
 > think it's better to just do nothing in the default handler: the
 > peripheral's interrupt will remain asserted and the correct vectored
 > interrupt will be entered subsequently (maybe not immediately if a
 > higher priority interrupt has happened in the meantime).
 >
 > As a note to Jaya: your concern over the UART CTI interrupt
 > being "ill conditioned" or "not latched" is misplaced. The statement
 > in the app note about a character being received clearing the CTI
 > interrupt is simply restating the UART description of the UART
 > Interrupt Identification Register (IIR): it will always happen,
 > regardless of whether or not there's a spurious interrupt (or even a
 > VIC for that matter). There's no suggestion that the interrupt isn't
 > latched and remain so until the IIR is read. My own previous
 > reference to this as "overwriting" may have been clumsy or
 > imprecise, but hardly "silly". You are of course entitled to your
 > opinion.

AN10414 very clearly states:

>Now lets consider that a CTI interrupt took place and the VIC reported 
>this event to the core. The core latched the IRQ state. So now the core 
>would be in step3 (Section 2.1). Lets assume that at this very moment a 
>character is received by the UART FIFO. This would clear the CTI interrupt 
>thereby causing a spurious interrupt.

 >
 > Brendan 

Send instant messages to your online friends http://au.messenger.yahoo.com