Jaya,
Since you keep asking, it doesn't take too much effort to find the
following:
http://document.sharpsma.com/files/tec_errata_LH7A404-SMA03018A.pdf
This describes a similar issue with an ARM/VIC part where the default
interrupt function is called in a spurious fashion. It may or may not
be exactly the same problem, but it does tend to support the argument
that the issue isn't unique to the Philips part.
My own interest is that some time ago we discovered this issue when
stressing the UART. We found that very occasionally (after a couple of
hours on a system with maybe 50k interrupts/second) the default
interrupt handler would be called. We reported the problem to Philips
(this was before there was either an app note or errata), who
acknowledged the problem, and subsequently published the relevant
information.
The interrupt is spurious in the sense that it happens and has no
value. If you don't want to handle the source of the interrupt in the
default interrupt handler, you don't have to. All you have to do is
acknowledge the VIC that it's been seen (the usual write to
VICVectAddr). If there is still an interrupt there, it will be handled
as normal. Obviously, if the source of the interrupt has gone (as in
the UART example where the received character will essentially
overwrite the CTI interrupt source) there's no need for anything else.
There's nothing been lost or not latched.
To be fair, this isn't totally clear from the Philips app note.
The bottom line though is that it's a known problem with a known
solution, so why labour the point?
Brendan
Dear Robert,
I am happy to share with you my knowledge about spurious interrupts, and my
understanding of what is happening.
--- In lpc2000@lpc2..., "Robert" <philips_apps@...> wrote:
> We would however greatly appreciate if you would provide your
> knowledge by investigating competitor devices using the VIC and
> telling this community if this is not a general ARM VIC as stated in
> the Application Note by running the same code on a competitor device
> not showing the problem and on a LPC2000 device, showing the issue.
As this is a LPC forum I will confine myself to what I know about LPC.
First let us look at the ARM FAQ 3677 that can be found at:
http://www.arm.com/support/faqip/3677.html
This document describes how this latency between the core receiving an
interrupt and taking that interrupt can give rise to two problems:
P1: If a procedure checks interrupt mask bits PSR to determine if it was
invoked anachronously (external interrupt) or synchronously (procedure
call), this can fail if the interrupt mask bits were changed during the
short interval between the core receiving the interrupt and taking the
interrupt.
P2: If both IRQ and FIQ are both disabled during the interval between the
core receiving and taking an interrupt, FIQ will be locked out for the
duration of the IRQ ISR.
Neither of these problems result in (or are related to) spurious interrupts.
This latency exists on all ARM cores of whether or not VIC exists. It does
not require OSes to accommodate spurious interrupts, quite simply because
none is generated as a consequence.
Now consider the Philips Application Note 10414 at:
http://www.standardics.philips.com/support/documents/microcontrollers/pdf/an10414.pdf
This document describes a different problem relating to "spurious
interrupts". The interrupts are spurious because the VIC is not able to
resolve the source.
Two scenarios are given, one relating to watchdog feed and the other
relating to UART RDA/CTI interrupts.
To understand what happens with the recommended method of disabling
interrupts while feeding watchdog, first consider how the ARM core and VIC
cooperate when handling interrupts.
The VIC raises an interrupt event. In response, the ARM core completes
whatever it is doing, including instructions already in its pipeline, and
then takes the interrupt by loading the PC with the address provided by VIC.
According to the AN, it appears that if one of the instructions in that
pipeline was clearing the interrupt enable flag of the VIC, then the VIC
loses track of the source of the interrupt.
Thus by the time the ARM core takes the interrupts, the VIC can only
provide the "default" address for the interrupt that occurred.
Hence although there was a legitimate interrupt, because the VIC was not
able to determine the source, this has now become a spurious interrupt.
This is why when a spurious interrupt occurs, the application must not
ignore it. It must do the task the VIC was designed to do by other means.
So essentially in the LPC, we have a VIC that fails when its interrupt
enable flag is being cleared. This is either a design or implementation
fault. If it were a design fault, then it would exist in any ARM+VIC as
the application note claims.
I feel it is unlikely that the ARM design is flawed to this extent that
makes the VIC unusable under many conditions for example when the system
cannot afford to miss a fast or vectored interrupt.
[When I get my OKI board which has VIC and watchdog just like LPC does, and
run your code on it, I will be able to say conclusively if this problem
generic to ARM+VIC ... at the moment I do not know and hence I asked for
references.]
Lets look at the second scenario for spurious interrupts relating to RDA
(receive data available) and CTI (character receive time-out) interrupts.
This AN states:
"Now lets consider that a CTI interrupt took place and the VIC reported
this event to the core. ... Lets assume that at this very moment a
character is received by the UART FIFO. This would clear the CTI interrupt
thereby causing a spurious interrupt."
Wait a minute! Does this mean that the UART raised CTI interrupt, and
before this interrupt could be serviced, changed its mind because it
discovered it received a character in the meanwhile? How come CTI
interrupt is not latched?
Is this not an excellent example of how to generate an ill conditioned
interrupt?
Not latching the CTI interrupt as in the LPC will create spurious
interrupts in any system because there is always a latency between
registering and taking the interrupt.
The bottom line for me (and the reason why I asked this question on the
web) is that I have a design coming with the OKI part to replace LPC. This
design cannot tolerate spurious interrupts. If I now the problem is VIC
specific, then I will be advising them to look for another part.
I have shot a question to ARM and I am not sure how long it will be before
I get a response. I will surely post the response if ARM allows me to.
Kind regards,
Jaya
PS: This is a rush off-the-cuff write-up -- if there are any errors that
obscures the explanation, feel free to correct and clarify.
Send instant messages to your online friends http://au.messenger.yahoo.com