Forums

Re: spurious interrupts on LPC

Started by Jayasooriah March 25, 2006
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

An Engineer's Guide to the LPC2100 Series

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.
>
> ______________________________________________________________________


Yahoo! Groups Links
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."
>Reply-To: l...
>To: l...
>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.
> >
> >
> >
> > ______________________________________________________________________
> >
> >
>
>

Yahoo! Groups Links
I am planning to do the same. It is really sad that
this forum occasionally generates SPAM.

Balaji

--- "George M. Gallant, Jr."
wrote:

> 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
>
=== message truncated ==
Dream is just a dream. A goal is a dream with a plan and a deadline.
- Harvey Mackay

Yahoo! Groups Links
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 l..., 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