Lpc2000

Ralph,

Many, many, thanks for your analysis: your explanation of my position 
is 100% accurate (in fact you do it better than I did, which might 
explain why this has gone on so long).

I think you've also done a fair analysis of Jaya's position (with 
which I've no argument): if he feels he can't live with spurious 
interrupts, that's fine. I genuinely mean it when I said I think his 
work is useful: any push that makes micros better, less prone 
to "quirks" etc. is all for the good. 

Unfortunately, we have to live with the products that are on the 
market today, not some idealised version that's theoretically 
possible, much as we'd like them. Hence my sharing of what we chose 
as a pragmatic solution, which as you (and others) have pointed out, 
is a well-established practice in any case. 

As an aside on this general theme, I think the Philips parts are 
about (or above) average in terms of their quirks.

Thanks again for taking the trouble with your message.

Brendan

--- In lpc2000@yahoogroups.com, Ralph Hempel <rhempel@...> wrote:
>
> 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.
>