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 

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