Lpc2000

Dear Ralph,

You started well but took a wrong turn.  This caused the flurry of noisy 
responses from the usual suspects.

Please refer to my reply by way of annotation (with noise deleted).

It would be nice if how could point out how you came that wrong conclusion 
(which I have clearly marked as "WRONG") so that I can fix it at the source.

Kind regards,

Jaya


>Message: 2
>    Date: Thu, 23 Mar 2006 10:06:20 -0500
>    From: Ralph Hempel <rhempel@...>
>Subject: Re: Re: spurious interrupts on LPC

...

>I've read Jaya's note on spurious IRQs at:
>
><http://www.cse.unsw.edu.au/~jayas/esdk/lpc2/spurious-irq.html>
>
>In short, he describes how VIC interrupt handlers are supposed
>to work, and provides short, simple, bits of code that can be
>easily understood.
>
>He then moves on to "surprise" interrupts, where he identifies
>the possibility that an interrupt handler may see the I bits in
>both SPSR and CPSR set at the same time if a disable CPU interrupt
>instruction is in the pipeline when the VIC interrupt is taken.
>
>He correctly identifies the fact that the handler should not
>use the state of the SPSR I bit to determine if it was invoked
>at interrupt time.
>
>So far so good.

Thank you.

>He then shows how to force the VIC to generate a spurious interrupt,
>and states:
>
>    "To avoid generation of such spurious interrupts in a system,
>     we must ensure no interrupt source exhibits transient behaviour,
>     and we should only clear the software interrupt in the interrupt
>     service routine."
>
>OK. So you can write a handler that only clears the software
>interrupt in the interrupt service routine, but you can't guarantee
>that other interrupt sources don't have transient behavior.

This is not my point.  I simply stated that you need to avoid interrupts in 
the system that exhibit transient behaviour to prevent this source of 
spurious interrupts.

>He also states in the section on the AN10414 Solution that:
>
>    "The implication here is that a surprise event generates only
>     one interrupt, and that this is a spurious interrupt.  However,
>     our experiment shows that such a surprise event generates two
>     successive interrupts,  a spurious interrupt followed by a
>     regular external interrupt.
>
>So, you don't lose the original interrupt, you just get a
>spurious one to whatever the default vector is FIRST.
>
>If I'm reading it correctly, Jaya's solution to spurious interrupts
>is to disable ALL interrupts when handling ANY interrupt.

WRONG.  Could you quote where in report I could have said anything that 
suggests this please -- so that I can correct it immediately.

This would be too expensive in any system.

>This is simply impractical in many applications.

It seems that you made an incorrect conclusion and then went off in a 
tangent, much to the bemusement of the usual suspects in this forum.

I need not consider the rest of your post that is based on a premise that 
is fundamentally flawed, because that was not the point I am making in my 
report at all.

>Now, from Brendan's point of view, I think I hear him saying that
>spurious interrupts are a fact of life in the VIC, and that you get
>the correct one afterwards anyways.

Brendans world is different to the deterministic world then.

>To make things very simple, we just accept that a spurious interrupt
>might happen, and deal with it as quickly as possible, then handle the
>real interrupt that is sure to follow.

Having alluded you to the dangers, it is your choice.

>I've been putting default handlers for unexpected sources for years.

I have been taking these out where programmers have put them for years.

>During the debug phase of the project, they point to a handler that
>logs the event and halts the system so I can figure out what
>happened and analyse the impact on the system.

And making this code benign in the field release is a popular misconception.

>For production, we just log the event and return to normal operation.

For high-rel systems, logging alone is not enough because it is an 
indication of problems to come in other parts of the system.

>Brendan's solution of being aware of the problem and forcing
>the default vector to a null handler is fine, from my point of view.

I would have said the same, if not for the fact that I was alluded to the 
fact that given the VIC "does not handle interrupts that exhibit transient 
behaviour", the behaviour of your system under these conditions is UNDEFINED.

>Jaya, I think Brendan is simply asking for proof one way or
>another that having a null handler for the VIC default vector
>is not going to work.

For proof, I would refer Brendant to PL190 design, and to speak to ARM 
engineers.  I have and I have made my conclusions based on the information 
I have been provided with.

>If you can provide solid proof with a reproducible example, then
>do so. He's not asking you to do his failure analysis for free,
>he's asking you to back up your statement that his solution is
>wrong with more than just handwaving.

I avoid spurious interrupts to save the expense of doing such an 
investigation because it works out cheaper.

Brendan can do this for his system with the very tools I have provided.

>Brendan, I think Jaya believes that the only way to prevent
>spurious interrupts is to disable interrupts at the processor
>level when handling interrupts.

WRONG.  Sorry for using UPPER CASE because this is what the usual suspects 
are rejoicing about, including Philips Apps.  This is not the solution that 
I recommended.

Again, if you can kindly point out how you came to this conclusion, please 
let me know so that I can correct my original report.

>I think that we'll all have to agree to disagree on the "correct"
>solution to the problem. Like many engineering tradeoffs, this
>one must be balanced by each individual on its own merits.

It is my observation (and that of many others working in this field) that 
many in the industry accept recovery solutions when they do not need to.

Your response to my report is an excellent example of how you can misread 
documentation and chose to live with it forever with band aids :)

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