At 10:31 PM 10/6/04 +0000, you wrote:
>This message was posted some months ago (early July):
>
>--- In lpc2000@yahoogroups.com, h s <h7242004@y...> wrote:
> > Has any one been able to successfully run all 4-compare channels of
>timer0 simultaneously (in the match interrupt mode, while the main
>timer0 is free running)?
> > The mode of operations could be such that one match channel is
>reloaded at a period rate. The other channels may be started and
>stopped as needed.
> >
> > I am losing match interrupts.
>
>I'm having exactly the same problem. MR0 is used to generate a system
>tick every 1ms and I periodically use MR1 and MR2 to generate
>interrupts every 26us and 52us respectively. Loading and starting of
>MR1 is synchronised to a capture input while loading and starting of
>MR2 is based on the program flow (MR1 and MR2 are used as a bit
>bashed serial port if you hadn't already guessed!). Multiple
>interrupt conditions can exist when the timer ISR is entered. A match
>is eventually missed on either MR0 or MR2.
>
>I've added debug code to store the TC value when the new match values
>are calculated and loaded. Every time the system stops working,
>examination of the debug variables show that TC value has advanced
>beyond the required match value, but no match interrupt seems to have
>been generated (and it's nowhere near a wrap either). Timer0 is set
>to increment every 1us and it generates the system's only FIQ. The
>time spent in any of the three associated interrupt routines is
>minimal - no longer than 4us, typically 2us. Any ideas?
Not in the timers but I've seen a similar effect on the serial port
(missing interrupts).
It behaved as if the transmit interrupt flag was cleared as it was set if
the IIR was read at the same time a character was received. I 'fixed' it
by not doing the usual loop on IIR until all flagged interrupts were
cleared but instead exiting after serving the first interrupt and allowing
the HW to reflag the interrupt.
IE instead of this loop in the interrupt routine
while( (x = IIR) != NO_INTERRUPT_PENDING) {
determine what interrupt is flagged by x and service
}
I changed to this
x= IIR
determine what interrupt is flagged by x and service
Not as efficient but I've not seen the problem reappear.
One thing to note: the condition flag on the uart itself was set properly,
just the IIR was wrong. If I added code to check for the transmit flag on
receiving a character the transmit would restart if a new character was
sent to the serial port.
Sound at all similar?
I've not seen any mention of this being duplicated by anyone. I don't like
my fix only because I'm not certain I've actually found the real problem.
Robert
>
>
>Yahoo! Groups Links
>
>
>
>
" '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