Lpc2000

At 09:09 PM 10/12/04 +0000, you wrote:
>There is a silicon bug, which Philips has confirmed, but has yet to
>publish.

Note to Philips: Timely publication of errata is a MUST.  If nothing else 
it saves a lot of bloody foreheads.


>If the timer hardware triggers an interrupt at the same time that the
>core is writing to the timer IR register to clear an interrupt on a
>different channel, the new interrupt does not get set.  This problem
>can occur with an input capture, as well as with a match.  That is a
>bit more difficult to work around.

That certainly explains it.

>As for there being a similar problem on the UART IIR, do you have a
>reproducible situation to determine this?

Yes, I did.  The situation came up while working with serial port 
interrupts (naturally).  It required that both transmit and receive 
interrupts be on simultaneously.  I then just had a simple echo program 
running on the micro and had the terminal emulator on the PC dumping a file 
continuously out the serial port.  At some point the echo would stop (it 
could take several Mbytes).  As in the timer case I couldn't see any 
possible way for the SW to miss the interrupt completely.

Two workarounds seems to 'fix' the problem
  - one was to check the transmit ready flags in the receive interrupt and 
restart the transmission if a transmit interrupt was missed,
  - the second was to only service a single interrupt source on each 
interrupt (only read IIR once)

The first workaround is obviously problematic since it requires a received 
character to restart the transmit.  The second one appeared to be 
successful, but since the bug appeared to be somewhat timing sensitive I 
don't know for sure if it was eliminated or simply had it's probability 
drop by an order of magnitude or so.

Note that the nature of the test would mask any missing receive interrupts 
if only an occasional character was dropped.  Receive should be more robust 
anyway since each receipt should conceivably re-trigger the interrupt 
whereas the transmit interrupt only fires once.

I don't think I kept the original failing code (silly me) but I should be 
able to reproduce it if anyone can make use of it.

I first reported on this in this group back on June 23 (see thread "Missing 
THRE interrupt?").  It was met with resounding silence so I thought I was 
the only one seeing anything like it until this timer interrupt thread.

I've been uncomfortable that I haven't been able to pin down a definitive 
cause but I've had other things to do so it's been on the back burner with 
a mental "Here be dragons!" sign for future attention.  You have just given 
me hope that the cause may yet be found (and more importantly confirmed).

>I suspect there are probably other registers (which can be written to
>by both the core and peripheral hardware) which exhibit a similar
>problem.  I don't know how much Philips has determined about the
>specifics and extent of this bug, since first confirming its
>existence.

Certainly if it exists for one peripheral it raises the possibility that it 
has occurred in others.

If I knew for sure that the problem was some sort of race condition there 
is a chance I could work around it.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III