Lpc2000

Wow!  Great analysis Ralph!  THANK YOU, Robert

Excellent filter applied to get out the essence of so many messages. 


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