Lpc2000

Jaya,

Three points:

- I specifically said that the Sharp problem may or may not be the 
same one: the point is that it is another example of a spurious 
interrupt using a similar setup (ARM + VIC + default interrupt being 
taken when it shouldn't). Frankly, I don't know how you can draw the 
conclusions you do with the very limited information provided. As 
I've already pointed out, it's irrelevant whether the cause is ARM 
or Philips in origin, which brings me to my second point...

- I could do comparative tests, but why would I (or anyone come to 
it) spend the time and effort on it? The problem exists, has been 
documented, and a fix provided. What more do you need? There are 
plenty of reasons to choose one micro over another, or even one ARM 
over another: this isn't one of them. You will find that OKI too 
have their quirks, some documented, some not. I'm not picking on OKI 
in particular here (it's a general statement): just that you 
mentioned them and I've experience of both OKI and Philips ARM 
parts. I'd recommend to anyone to look at the information provided 
in order to make the choice. 

- If you think what I say makes me look silly, that's fine by me 
(your comment says far more about you than me). I've said it before: 
people will make their own minds up on what anyone says here, based 
on the evidence provided. I'm happy to stand over anything I've said 
here, or to correct it if it is indeed wrong.

Brendan

--- In lpc2000@yahoogroups.com, Jayasooriah <jayasooriah@...> wrote:
>
> 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
>