Lpc2000

Jaya,

Who cares?

Brendan

P.S. It's no wonder you're tired: that's a lot of typing you've done 
there! Maybe you should rest a while....


--- In lpc2000@yahoogroups.com, Jayasooriah <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
>