Lpc2000

With apologies to all for the length of this post….

Jaya,

Many thanks for your response: I think it well worth it to try and 
get to the bottom of this.

--- In lpc2000@yahoogroups.com, Jayasooriah <jayasooriah@...> wrote:
>
> 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.

I'd be curious to know which parts of the post contradict the many 
findings of these different people: can you supply an example, 
please?

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

I wasn't being vague, simply summarising in as brief a form as 
possible the well-documented issue, that as you point out has 
already been explained precisely elsewhere. Try reading it again and 
telling me which part is inaccurate or wrong: "…in certain 
conditions the VIC doesn't provide the correct vector address…". Why 
bother repeating the details?

As for the underlying cause, I'm sure Philips (and ARM, if it's an 
ARM issue) are very well aware of the underlying cause. It's of no 
interest to me though: all I'm interested in is the observed 
behaviour. I'm particularly not interested in speculating on the 
underlying cause, attempting to use incomplete information to draw 
wild conclusions.

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

Can you explain this last statement, please? I'm fascinated.

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

It's not necessary to poll the interrupt sources if you're not 
interested in handling the source of the spurious interrupt within 
the default interrupt handler. Maybe you should read my post again? 
True, it's something of a work around having a spurious interrupt 
handler to handle a spurious interrupt, but as I pointed out, one 
that's very easy and simple to live with (and as others have pointed 
out, good programming practice in any case).

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

You'll have to explain the relevance of this last statement to me.

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

Can you supply some evidence that it won't work, please? I'd love to 
hear it. 

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

Agreed, this is all certainly true, but only if you want to handle 
the source of the interrupt in the default interrupt handler, which 
is what the app note is all about. My point is that you don't have 
to. If I'm incorrect in this, I'm perfectly willing to admit I'm 
wrong (I've been wrong many times before), but I'd like to see some 
evidence first, or explanation from a credible source. By "credible" 
by the way, I mean Philips or ARM.

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

Agreed: all true. If you read my post again you will see that I 
explicitly mentioned you have to do this, even in an otherwise empty 
interrupt handler. If you don't (read or write to the register that 
is) you're on your own.

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

Agreed: I think I used the term "misguided". The basic solution – to 
provide a default interrupt handler – is however quite valid, simple 
to implement and easy to prove correct.

> 
> [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.]

I'd can't wait to see it! I assume you'll post it here?

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

Jaya, I can assure you I do appreciate this problem. As I think I 
mentioned we actually experienced it before it was documented. The 
system we discovered it on has many, many interrupts, from different 
sources, at different rates (inclduing randomly), and different 
priorities. I won't bore you or anyone else with the details: I find 
it somewhat tedious when people describe in great detail how complex 
their systems are, assuming they are somehow unique in this respect. 

[Text removed here]

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

I meant rare in the sense it doesn't happen very often on a 
particular system, not that it has been rarely observed by different 
people. 

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

We'll just have to disagree on this one: all I can say is that it's 
a moot point for me, and I suspect most other people. To use an 
analogy: if there's a problem with your Ford, and they blame a 
component manufacturer, it might be of interest to you if you choose 
your cars based on the behaviour of individual components, but it's 
pretty academic to most people: they just want a car that works.

> 
> [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.

Again, maybe I'm slow, but can you explain why it isn't?

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

It's not ignoring the interrupt: just not handling it in the default 
interrupt handler. As I explained, it will be handled later, as the 
peripheral causing it will still be asserting it.

[More text removed here]

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

Can you explain this live-lock situation and how it might arise?

[More text removed here]

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

Correct! and all entirely consistent. As the UART description makes 
clear, receiving a character (activity in the FIFO) will clear the 
CTI interrupt. As the app note makes clear, changing the status 
during this critical period causes the spurious interrupt. I suggest 
you work through the details of how back-to-back CTI and received 
character interrupts are handled (with and without a VIC, with and 
without spurious interrupts) and all should become clear. Don't 
forget not to confuse acknowledging interrupts in the peripheral and 
acknowledging them in the VIC.

With best wishes.

Brendan