Yahoo Groups archive

Lpc2000

Index last updated: 2026-04-28 23:31 UTC

Message

Re: [lpc2000] Undocumented Timer Interrupt Feature, or Silicon Bug...

2004-10-12 by Robert Adsett

At 08:03 PM 10/11/04 +0000, you wrote:


>...Or am I doing something wrong?
>
>I've been implementing a bit bashed serial port on an LPC2114. The
>code relied upon the timer module's input capture facility to
>generate an interrupt whenever there was a 1->0 or 0->1 transition on
>the RS232 receive line (buffered by  a Max232 equivalent). This
>loaded a match register (MR1) with a value equal to half a bit time
>so the incoming bit could be sampled at its mid-point. Transmission
>used another match register (MR2) to generate appropriately timed
>interrupts to send bits as required. Another match register (MR0) in
>the same timer was also used to generate a 1ms tick.
>
>When I was testing the code's full duplex operation, I found that the
>1ms tick or the transmission tick interrupt would sometimes be missed
>(refer to posts 3510 and 3514). Robert Adsett suggested not servicing
>multiple events in the ISR. This did not fix the problem. The only
>way I've found to work around the problem of missing interrupts is to
>stop the counter while I process any pending match or capture
>interrupts. Is this an undocumented feature 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?

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.

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.

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

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.