Lpc2000

See the "Timer_Issue" pdf in the file section, it will be removed 
when the updated errata is published.

Philips Apps.

--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...> 
wrote:
> 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