Lpc2000

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