Lpc2000

Brendan,

Superfifically it looks like the same problem but if you read it you should 
be able to work out that the spurious interrupt problem in LPC is different 
to the spurious interrupt in LH implementation:

1/  The VIC problem described in paragraph 16 relates to race condition 
that exists when two interrupts occur at the same time, one of which goes 
through the VIC.

The legitimate interrupt received by the VIC is not lost, but delayed until 
after the spurious interrupt is taken.  Thus the spurious interrupt ISR 
does poll all sources of vectored interrupts.

In the case of LPC, a legitimate interrupt is lost when VIC interrupt 
enable flag is being cleared as it occurs.  This is why the spurious 
interrupt ISR here must scan all sources of *vectored* interrupts.

2/  The MMC problem described in paragraph 17 relates to MMC, not VIC. If 
it were a VIC problem, then it would apply to other interrupts besides MMC, 
and it does not.  Also we should be able to see this on LPCs too if it was 
ARM + VIC implementation issue, but this appears not to be the case.

Also, Sharp does not claim the problems in their implementation is generic 
to any or all other ARM + VICs.  If it were, the same bug would show up in 
LPC too, but this does not seem to be the case.

Philips claims this bug exists in all ARM7TDMI with VIC. If this claim were 
true, we should see reports of such spurious interrupts on other variants, 
but this appears not to be the case.

Have you any other references that says this is a generic ARM7TDMI + VIC 
problem.  For example, can anyone run the Philips watchdog experiment on 
any of the other variants and say if the same problem exists?

I have asked people to try and no one has been able to repeat this on any 
of the other ARM variants so far.

One more thing Brendan, trying to mitigate effects of not latching CTI in 
the UART implementation only makes you look silly because the VIC 
specifications is very clear (see Note on page 2-2 of TRM) that it does NOT 
handle interrupt sources with transient behaviour.  Period.

Kind regards,

Jaya

--- In lpc2000@yahoogroups.com, "brendanmurphy37" <brendan.murphy@...> wrote:
 >
 >
 > 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

Send instant messages to your online friends http://au.messenger.yahoo.com