Lpc2000

Thanks for the confirmation. And thank you to Robert for his prompt 
and insightful replies.

Now, time to go and fix that wall that I'd been bashing my head 
against... :-)

Regards




Vaughan

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