Lpc2000

There is a silicon bug, which Philips has confirmed, but has yet to 
publish.

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.

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

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.



--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...> 
wrote:
> At 12:42 AM 10/12/04 +0000, you wrote:
> 
> 
> >--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...>
> >wrote:
> > > At 08:03 PM 10/11/04 +0000, you wrote:
> > >
> > >
> > > >...Or am I doing something wrong?
> > > No answers, only questions.
> > >
> > > You are running at full speed, ie MAM fully enabled, a divisor 
of 1
> > > on the peripheral bus?
> >
> >External clock is 10MHz, PLL is enabled and multiplies this to 
60MHz.
> >MAM is enabled and MAMTIM is set to 3. VPBDIV is set to 1. As far 
as
> >I can see, the core is working at 60MHz (e.g. baud rate divisors 
work
> >out as expected for this value). Interestingly, I tried clocking TC
> >at this rate (i.e. one count every 16.7ns) with appropriate MR
> >values. The problem I've outlined was much much worse i.e. 
interrupts
> >were lost almost immediately.
> 
> Interesting, not sure what that means but interesting.
> 
> > > Have you measured how long an interrupt takes?  IE done 
something
> >like
> > > toggle a pin at the beginning and end of your dispatch 
routine?  If
> > > possible I'd consider generating assembly from the C and 
inserting
> >the pin
> > > toggle as close to the start and end of your interrupt as
> >possible.  I'm
> > > wondering if latency or simple overhead and execution time 
isn't a
> >part of
> > > the issue.
> >
> >That's what I initally thought. However, the final code only takes
> >around 2us to action ANY of the various events. Assuming ALL events
> >occur simultaneously, I could get a maximum of 6us latency (give or
> >take!). The sample code I posted also exhibits the same behavior 
and
> >it is very minimalistic (I didn't measure the various execution 
paths
> >but I would be surprised to see any event taking much longer than 
1us
> >to process). Also, my bit bashed port with the clock stopping
> >workaround is very reliable at 9600 bps full duplex and passably so
> >at 19k2 full duplex. This wouldn't be the case if my event 
processing
> >was taking a long time.
> 
> That's sort of what I was expecting, but it did need to be checked.
> 
> 
> >I think your previous post hit the nail on the head - when there 
are
> >simulataneous accesses to an interrupt register, it does not
> >accurately reflect what's happened.
> 
> And on reflection, I'm wondering if it isn't more similar to what I 
saw on 
> the serial port IIR than I first thought.  What I saw appeared to 
behave as 
> if the interrupt flag was lost if the event causing the interrupt 
occurred 
> at the same time that the previous interrupt condition was being 
> cleared.  You do have places where that sequence can occur and 
turning off 
> the counter would eliminate the problem (no interrupt source, no 
chance of 
> conflict).
> 
> If that is the case it should be possible to narrow the region that 
the 
> clock/counter must be disabled.
> 
> Specifically you have several lines of this form
> 
>              TIMER0_IR = TIMER0_IR_CR1;
> 
> to clear the interrupt source just serviced, and you (in 
your 'working' 
> version) disable the counter for the entire interrupt.  If you 
replace the 
> above line with
> 
>      TIMER0_TCR = 0; /*Stop the clock before clearing the interrupt 
source. */
>      TIMER0_IR = TIMER0_IR_CR1;
>      TIMER0_TCR = 1; /*Restart the clock*/
> 
> then if that hypothesized race condition actually exists you should 
still 
> be protected against it (I suppose it might be possible you would 
have to 
> wait an instruction for the counter to stop).
> 
> Hmm, this might also explain why a faster counter showed the 
problem more 
> readily.  A faster counter would be more likely to have an edge 
just as the 
> constant was being stored in TIMER0_IR.
> 
> If you try this please let us know.  I, for one, would be very 
interested 
> in the results.
> 
> 
> > > One of the reasons I'm asking is I did some measurements on 
timing
> >(polled,
> > > no Interrupts) and found that the smallest time period I could
> >effectively
> > > wait for was about 11uS.  That obviously included overhead but 
your
> > > routines will too.  If your timing was similar (and I would 
naively
> >expect
> > > it might be faster) then that would give an overhead of 44uS if 
all
> >four
> > > happened at the 'same' time.  That's close enough to your 52uS
> >cycle time
> > > that I'd want to check how long it was actually taking.
> >Hmmmm.... It still shouldn't miss events though!
> 
> Well, it might, if you wrote to clear an event just as (or after) a 
second 
> one of the same kind had been flagged.  That doesn't fit with your 
timing 
> though.  I think the possibility of a HW race is a better fit to 
the 
> observations, ugly though.
> 
> 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