Lpc2000

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]