Lpc2000

Hi George

<<<
>Congratulations. You are the first person I have ever created a filter
>to automatically route
>all email from directly to the trash bin!
>>>

This process is called plonk!
It is used in newsgroups to tell a troll,
that his threads are now directed to the trashcan.
It is an acronym for
please leave our newsgroup, kid
or describes the sound when his threads hit your trashcan.

Cheers
Michael


>From: "George M. Gallant, Jr." <ggallant571@...>
>Reply-To: lpc2000@yahoogroups.com
>To: lpc2000@yahoogroups.com
>Subject: Re: [lpc2000] Re: spurious interrupts on LPC
>Date: Sat, 25 Mar 2006 09:43:22 -0500
>
>Jayasooriah,
>
>Congratulations. You are the first person I have ever created a filter
>to automatically route
>all email from directly to the trash bin! I won't even get your
>everlasting nonsensical replies!!!!
>
>George
>
>On Sun, 2006-03-26 at 00:03 +1100, Jayasooriah wrote:
>
> > Hello,
> >
> > For what it is worth, here is a summary of the issues surrounding the
> > very
> > first question I raised relating to spurious interrupts on LPC 2000
> > family.
> >
> > A different perspective emerges you look at the distractions by way
> > of
> > noise generated those whom I have labelled "the usual suspects".
> >
> >
> > ==> 2006-03-14 21:40:10 GMT Jayasooriah
> >
> > I looked at LPC200 FAQ claim that spurious interrupts can occur in any
> > ARM7
> > that incorporates the VIC.  I was surprised and I asked Robert
> > (Philips) to
> > clarify:
> >
> > 1/  Is the spurious interrupt problem specific to implementation of
> > VIC on
> > LPC, or is it a generic VIC problem?
> >
> > 2/  Do any other ARM cores with VIC suffer from the same problem?
> >
> > [Has anyone answered this question?  No?  Yes ... no!]
> >
> > ==> 2006-03-15 00:12:07 GMT Robert (Philips)
> >
> > Forwarded my question the author of the FAQ.
> >
> > [Neither Robert nor Philips has provided any response from the author
> > to date.]
> >
> > Asks me to investigate this on other ARM variants and report my
> > findings.
> >
> > 2006-03-15 07:06:37 GMT Jayasooriah
> >
> > I respond by saying that none of the other variants make this claim.
> >
> > I reiterate that I am looking for references to substantiate the claim
> > in
> > Philips LPC200 FAQ and Applicaition Note 10414 that all ARM7 variants
> > with
> > VIC suffer from spurious interrupts that LPC suffers from.
> >
> > [To date, there has been no reference from Philips, Robert or anyone
> > else
> > for that matter to substantiate this claim.]
> >
> > I did lookup references to spurious interrupts in relation to ARM7 and
> > most
> > of them come back to LPC2000.  There was even a reference to LPC2000
> > in
> > relation to spurious on lecture notes in a University course!  It does
> > look
> > like the LPC family is very well known for its spurious interrupts
> > like no
> > other processor.
> >
> > I will admit I found few references relating to peripheral on
> > particular
> > ARM variants, but these appear to be peripheral specific -- there has
> > been
> > no other claim I can find that attributes the issue as generic to any
> > ARM7
> > + VIC.
> >
> > We did not get an answer to the question, but we did have a very
> > active
> > thread with lots of distractions from the usual suspects:
> >
> > Distraction #1:  ARM FAQ 3677 explains spurious interrupts in ARM7.
> >
> > At first there was rejoicing amongst the usual suspects at how quickly
> > my
> > question was dealt given it looked I was challenge the legitimacy of
> > a
> > claim by Philips.
> >
> > When we got to the bottom of this and learnt of the subtle difference
> > between spurious and surprise interrupts, and that this FAQ discusses
> > surprise interrupts, not spurious interrupts, the usual suspects went
> > quiet
> > for a while ...
> >
> > Then someone who claimed to have many years experience in this field
> > made a
> > bungle and claimed that my solution does not allow nested interrupts.
> >
> > Distraction #2:  My solution is not acceptable because it does not
> > allow
> > nested interrupts.
> >
> > There was another round of rejoicing from the usual suspects, that my
> > solution is not accepted to anyone in the real world.
> >
> > I pointed out the bungle.   Things went quiet for while.
> >
> > There was this one person who persisted on having his implementation
> > validated by by me through this forum.  This led to a further
> > incorrect
> > claim relating to my solution.
> >
> > Distraction #3:  My solution in relation to UARTs is not a solution
> > because
> > one cannot use the UART if one do not enable receiver interrupts.
> >
> > I pointed out that how one uses timer interrupts to receive characters
> > as
> > the UARTs have a FIFO in the receive channel, and that this method has
> > been
> > put to practice and shown to work.
> >
> > The same persistent person then picks up another issue in relation to
> > validating his solution, regarding my statement that what happens in
> > the
> > case of what this person was doing is undefined.
> >
> > Distraction #4:  Prove the VIC behaviour is "UNDEFINED" if one polls
> > interrupt sources one by one in the "spurious interrupt handler".
> >
> > I point out that I cannot define the behaviour because the PL190 TRM
> > clearly states this something it was not designed to handle, and that
> > if
> > such an event did occur, its priority logic cannot cope with it.
> >
> > I did say that came to this view having discussed the matter with ARM,
> > and
> > having read responses from engineer in ARM working on PL192 design.
> >
> > [PL192 is the successor to PL190 and it can handle interrupts RDA/CTI
> > type
> > of interrupts from UART0/1 on LPC family.]
> >
> > I pointed out that reading and writing to the VIC vector when you do
> > not
> > know the cause of the interrupt is documented in PL190 as
> > unpredictable.
> >
> > Now there was another rejoice ... but exactly for what reason I am
> > not
> > sure.  It  appears to do with someone claiming of having run tests for
> > a
> > long time and not having had a single spurious interrupt over this
> > time.
> >
> > After all the distractions it does not seem to matter that not one
> > person
> > has been able to provide one shred of evidence, or even a reference
> > to
> > substantiate the claim by Philps that started this thread.
> >
> > We now know for a fact, from ARM, that any ARM variant that
> > incorporates
> > PL192 VIC will not support interrupts of the type originating form
> > UART0/1
> > on LPC family.
> >
> > It does not seem to matter that, because the LPC's world spins around
> > the
> > PL190 design as implemented on LPCs, and has problems with its UART0/1
> > that
> > generates spurious interrupts.
> >
> > Now lets turn to the solutions I proposed that is based on
> > *preventing*
> > spurious interrupts altogether on the LPC.  This has been formally
> > documented and available on-line for anyone to comment on.
> >
> > As far as AN10414 is concerned, there are two scenarios that generate
> > spurious interrupts on LPC: a) when an interrupt are disabled through
> > VIC
> > as it occurs; and b) when CTI and RDA interact within the UARTs in
> > transient manner that any PL190 based VIC does not support.
> >
> > In relation the first problem:
> >
> > * My solution to Philips AN10414 watchdog problem is downright simple:
> > use
> > CPSR instead of VIC that Philips recommends.  It is not a matter of
> > preference as one poster put it, but a matter of either preventing or
> > handling spurious interrupts.
> >
> > * I also showed how one can disable a particular interrupt using the
> > VIC if
> > one brackets this operation using masking operations on CPSR.
> >
> > One asks why the above solution is unacceptable to the usual suspects.
> > It
> > appears that if this solution were acceptable, then they would have
> > to
> > admit that RDA/CTI is not relating to ARM7+VIC ...
> >
> > Given the UART RDA and CTI interrupts exhibit transient behaviour that
> > is
> > not handled by the VIC, it is easy for me to say "do not use these
> > interrupts". Of course Philips cannot say the same without admitting
> > to a
> > flaw in the UART0/1 design.
> >
> > There were claims that my solution meant one cannot use UARTS at all
> > -- but
> > hang on, I did show how one can use the UARTs but without using
> > RDA/CTI
> > interrupts.  This appears to have been buried in the noise generated
> > by the
> > usual suspects.
> >
> > Someone said to me a while ago, when one participant was continually
> > pestering me for answers, that I should have simply told this person
> > to
> > point out where it says the behaviour of VIC is defined when an
> > interrupt
> > exhibits transient behaviour.
> >
> > I thought it would be kinder for me to keep explaining in different
> > ways
> > until this person eventually catches on to how my solution removes
> > spurious
> > interrupts altogether nice and simple.
> >
> > Guess what?  I think my explanation worked if I am to read the many
> > emails
> > I have had arising from opening up my analysis and conclusions on-line
> > for
> > comment.  Even this persistent poster appears to have understood it
> > somewhat!
> >
> > Judging from the fact that my critics in this forum have yet been
> > unable to
> > fault my findings or solutions, we actually ended up solving the
> > problem in
> > the best way possible -- without generation of a single spurious
> > interrupt
> > in the system.
> >
> > I am encouraged by the responses I got to my analysis of LPC spurious
> > interrupts and calls for the same level of documentation for the
> > other
> > problems I found.
> >
> > Have a browse through this thread on GMANE and you will see what role
> > Philips has been playing in this forum, in this thread in particular.
> >
> > I was told that that Philips is here for no other reason that to
> > promote
> > its LPC family of products.  I said to the effect that is is not a
> > bad
> > thing.  But I was reminded there is a complimentary role to play that
> > involves gagging threads that dwell in (potentially serious) flaws in
> > LPC
> > family.
> >
> > The issues I have raised certainly appear to dwell in flaws to a
> > large
> > extent, and there is no doubt in my mind that Robert (of Philips) is
> > doing
> > what he is expected to do under the circumstances.
> >
> > It is a pity the usual suspects see virtue in gagging independent and
> > unaligned discussion of the problems raised here relating to various
> > aspects of the LPC, be it code security, watchdog anomalies, flash
> > deficiencies or spurious interrupts.
> >
> > Enjoy.
> >
> > Jaya
> >
> > Send instant messages to your online friends
> > http://au.messenger.yahoo.com
> >
> >
> >
> > ______________________________________________________________________
> > YAHOO! GROUPS LINKS
> >
> >
> >      1.  Visit your group "lpc2000" on the web.
> >
> >      2.  To unsubscribe from this group, send an email to:
> >          lpc2000-unsubscribe@yahoogroups.com
> >
> >      3.  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
> >         Service.
> >
> >
> >
> > ______________________________________________________________________
> >
> >
>
>
>[Non-text portions of this message have been removed]
>