Lpc2000

Umm...  2 solutions for the "root" of the problem??

Option 1:
If an O/S cannot work with the LPC2xxx chip, throw away the 
LPC2xxx chip.  Why want to patch the O/S code to make it 
functioning with LPC2xxx?  Can that O/S be then *CERTIFIED* to be
reliable after that *Spurious Interrupt* code patch??
=> Why NOT pick some other vendor's chip.   Are ARM7 chips from
Atmel,STMicro,Sharp,CirrusLogic or TI inferior to Philips Chips??

Option 2:
3000 members here and eCos, uCLinux, FreeRTOS do not have problem
with the LPC2xxx Chip's Spurious Interrupt. => So Trash that O/S...

If you have another option, let me know...  :)
Regards


--- In lpc2000@yahoogroups.com, "brendanmurphy37" 
<brendan.murphy@...> wrote:
>
> 
> 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.
> >
>