Lpc2000

I was having the same problem with one of the capture interrupts; the
interrupt was configured to be rising-edge-triggered and was
multiplexed together with the other timer interrupt sources including
a fast match interrupt (every 10ms).  The match interrupt clear would
occasionally clear the capture interrupt before it had been serviced. 

The test to see if this was happening also turned out to fix the
problem:  in the ISR, if the capture interrupt flag was not set, I set
the pin_connect block to make the capture input a GPIO, read the state
of the input pin, and then set it back to a capture input.  This
confirmed the problem (input was high (active) but interrupt flag was
clear) and also seemed to solve it...I suspect when I turned the pin
from GPIO back into a capture pin, it saw a transition, the interrupt
fired, and the ISR serviced the peripheral.

Can you confirm this mechanism?

--- In lpc2000@yahoogroups.com, "philips_apps" <philips_apps@y...> wrote:
> 
> 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