Lpc2000

Honestly, this is getting ridiculous.

I actually read this thread just in case some nugget of
information pops out :-)

I've been writing code for embedded systems for 20 years and
have seen a lot of failures and issues with root causes in
the interrupt handlers. I'll try to find common ground in
both positions so we can give this dead horse a decent burial.

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.

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.

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.

This is simply impractical in many applications.

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.

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.

I've been putting default handlers for unexpected sources 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.

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

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.

If Jaya's customers don't like spurious interrupts, then they can
either use Jaya's solution, or switch chip architectures.

If Jaya's solution means the application does not meet real-time
commitments then his customers can either choose Brendan's
solution or switch chip architectures.

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.

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.

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

It works, it's just that you (and many others) think it's
impractical.

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.

Ralph Hempel - P.Eng.