Jaya,
Many thanks for providing additional information on the problems
with spurious interrupts as you see them, and your proposed
solutions.
Unfortunately, in the case of the UART sourced interrupt, it's no
real solution simply to say "don't use the UART with receiver
interrupts enabled". It also doesn't take account of other
peripherals that may exhibit transient behaviour.
A simple, empty, default interrupt handler will enable you to use
whatever interrupts you like. If you have information to the
contrary, I'd be interested to hear it.
Thanks again for the interesting explanations.
Brendan
--- In lpc2000@lpc2..., Jayasooriah <jayasooriah@...> wrote:
>
> Dear Robert (from Philips),
>
> I have presented my findings on what causes spurious interrupts on
LPC
> family of processors, and how one can prevent
their occurrences at
(E&OE):
>
> http://www.cse.unsw.edu.au/~jayas/esdk/lpc2/spurious-irq.html
>
> In the process of doing this, I needed to explain what is
incorrect with
> the solution recommended in Philips Applicaiton
Note 10414. I
have
> attached my summary below.
>
> Under the circumstances, I would like to provide you (Philips) an
> opportunity to examine my analysis. Could you kindly assist in
passing on
> the reference to your technical people so that
they can point out
where the
> consider I have erred in relation to the conduct
of the
experiments, or in
> making conclusions from the results.
>
> I conducted these deterministic experiments on LPC2292 with
14.7456 MHz
> crystal, with PLL and MAM in their reset state,
that is disabled
and with
> maximum delay, respectively. The code runs
entirely from on-chip
RAM.
>
> I am happy to consider all rebuttals, and amend this report of my
findings.
>
> Kind regards,
>
> Jaya
>
> >Spurious interrupts are generated on LPC family of processors
under two
> >scenarios. One of these presents itself when
the VIC receives an
> >interrupt as it being disabled. The other arises from the the
transient
> >behaviour of the RDA and CTI interrupt sources
that originate
from its
> >UART0/1 peripheral devices.
> >
> >The solution proposed by Philips in AN10414 involves servicing
spurious
> >interrupts by a parallel handler and involves
polling and
servicing of
> >interrupts from all sources within this
handler. This method
does not
> >work in a system if interrupt nesting is
allowed.
> >
> >The spurious interrupt handler operating in this way can result
in the
> >generation of further spurious interrupts.
> >
> >It is possible to prevent spurious interrupts on LPC2000 by not
using the
> >VIC to disable interrupts, using the I and F
bits of CPSR
> >instead. Interrupts can be disabled at the VIC if the interrupt
sources
> >can be shut down by other means, for example
by disabling
interrupts at
> >the peripherals themselves.
> >
> >As some UART peripheral interrupts exhibits transient behaviour
that is
> >not handled by the VIC by design, these
interrupts cannot be
handled
> >through the VIC if interrupts are nested.
>
>
> Send instant messages to your online friends
http://au.messenger.yahoo.com
>
Dear Robert (from Philips),
I have presented my findings on what causes spurious interrupts on LPC
family of processors, and how one can prevent their occurrences at (E&OE):
http://www.cse.unsw.edu.au/~jayas/esdk/lpc2/spurious-irq.html
In the process of doing this, I needed to explain what is incorrect with
the solution recommended in Philips Applicaiton Note 10414. I have
attached my summary below.
Under the circumstances, I would like to provide you (Philips) an
opportunity to examine my analysis. Could you kindly assist in passing on
the reference to your technical people so that they can point out where the
consider I have erred in relation to the conduct of the experiments, or in
making conclusions from the results.
I conducted these deterministic experiments on LPC2292 with 14.7456 MHz
crystal, with PLL and MAM in their reset state, that is disabled and with
maximum delay, respectively. The code runs entirely from on-chip RAM.
I am happy to consider all rebuttals, and amend this report of my findings.
Kind regards,
Jaya
>Spurious interrupts are generated on LPC family of
processors under two
>scenarios. One of these presents itself when the VIC receives an
>interrupt as it being disabled. The other arises from the the transient
>behaviour of the RDA and CTI interrupt sources that originate from its
>UART0/1 peripheral devices.
>
>The solution proposed by Philips in AN10414 involves servicing spurious
>interrupts by a parallel handler and involves polling and servicing of
>interrupts from all sources within this handler. This method does not
>work in a system if interrupt nesting is allowed.
>
>The spurious interrupt handler operating in this way can result in the
>generation of further spurious interrupts.
>
>It is possible to prevent spurious interrupts on LPC2000 by not using the
>VIC to disable interrupts, using the I and F bits of CPSR
>instead. Interrupts can be disabled at the VIC if the interrupt sources
>can be shut down by other means, for example by disabling interrupts at
>the peripherals themselves.
>
>As some UART peripheral interrupts exhibits transient behaviour that is
>not handled by the VIC by design, these interrupts cannot be handled
>through the VIC if interrupts are nested.
Send instant messages to your online friends
http://au.messenger.yahoo.com