Forums

lpc2138 uart1 drops interrupts

Started by adrianunderwater April 10, 2008
Hi

I have a following problem that I just can't get my head around. I
wonder if anyone else experiences this or if I have not stumbled upon
the right errata sheet....

Most of the code is written in Assembly

There are 4 IRQ interrupt sources;
priority 0 = timer0
priority 1 = timer1
priority 10 = uart0
priority 11 = uart1

uart0 is only used for debugging and interacting with the board.
(There is a full fledged custom operating system on the board)

timer0 runs at 100 microseconds and does stuff...

timer1 is disabled

uart1 runs at 38400bps, receives a frame of 14 to 18 bytes every 10
milliseconds and responds with a frame of 14 to 18 bytes each time.
Comms are half duplex, and the uart 'sees' everything it sends.

The VIC interrupt routines are not nestable, i.e. I do not change the
cpcr register to system mode in the int. But on entry and exit I do
push and pop the necessary registers for the interrupt routine.

I stay within the uart1 interrupt routine until all interrupt sources
are cleared.

When the application runs, maybe every 4 or 5 hours uart1 drops an
interrupt. Considering that there are 100 messages per second, and
each message generates 3 (or in another debug version 16) tx
interrupts that means that there is a dropped interrupt every million
or so interrupts.

I have examined in detail the interrupt routines, the VIC settings the
UART settings etc.. I have looked at the errata sheets concerning
uart1 but failed to see a connexion between the problems reported and
what I am seeing.

Would anyone have some sort of idea I could investigate?

Many thanks, Adrian

An Engineer's Guide to the LPC2100 Series

On Fri, 11 Apr 2008 00:44:20 -0000, you wrote:

>Hi
>
>I have a following problem that I just can't get my head around. I
>wonder if anyone else experiences this or if I have not stumbled upon
>the right errata sheet....
>
>Most of the code is written in Assembly
>
>There are 4 IRQ interrupt sources;
>priority 0 = timer0
>priority 1 = timer1
>priority 10 = uart0
>priority 11 = uart1
>
>uart0 is only used for debugging and interacting with the board.
>(There is a full fledged custom operating system on the board)
>
>timer0 runs at 100 microseconds and does stuff...
>
>timer1 is disabled
>
>uart1 runs at 38400bps, receives a frame of 14 to 18 bytes every 10
>milliseconds and responds with a frame of 14 to 18 bytes each time.
>Comms are half duplex, and the uart 'sees' everything it sends.
>
>The VIC interrupt routines are not nestable, i.e. I do not change the
>cpcr register to system mode in the int. But on entry and exit I do
>push and pop the necessary registers for the interrupt routine.
>
>I stay within the uart1 interrupt routine until all interrupt sources
>are cleared.

Presumably you mean all UART 1 related int sources....

>When the application runs, maybe every 4 or 5 hours uart1 drops an
>interrupt. Considering that there are 100 messages per second, and
>each message generates 3 (or in another debug version 16) tx
>interrupts that means that there is a dropped interrupt every million
>or so interrupts.
>
>I have examined in detail the interrupt routines, the VIC settings the
>UART settings etc.. I have looked at the errata sheets concerning
>uart1 but failed to see a connexion between the problems reported and
>what I am seeing.
>
>Would anyone have some sort of idea I could investigate?
>
>Many thanks, Adrian

What exactly do you mean by 'drops an interrupt'?

Are you handling unexpected interrupts correctly ?
Typically this just means having a null handler and making sure you empty the fifo in your rx
service code.
The situation that causes these is where you get an RX timeout int, but in the time between the int
happenning and your service code getting called, more characters come in, so the timeout int source
gets cancelled before you see it (but there aren't yet enough new chars to cause a fifo interrupt)
and the VIC doesn't know what to do with it.
As this is obviously a very rare occurrance, its probability may be comparable to the error rate you
are seeing so may be worth thinking about whether it may be relevant.