Lpc2000

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