EmbeddedRelated.com
Forums

LPC2136 problems receiving at high baudrates

Started by Mike Harrison November 21, 2007
I'm having problems getting reliable UART receive operation at baudrates of 1mbit/sec & above.
PCLK is 60MHz, and baudrate is definitely set correctly as verified by looking at TX data on scope,
and the sent data is also correct ( coming from an FT232R).

What seems to be happenning is that the UART gets into a state where it appears to be receiving data
( correct number of bytes) , but the data is garbage, but no framing or overrun errors are
occurring.
After a reset, it will either start receiving OK and continue OK indefinitely., or it gets into the
above state, never receiving good data, from which it doesn't seem to be able to recover.

by setting I/O flags in various parts of the code, what appears to be happenning is that on getting
the receive interrupt, the loop that empties the fifo is seeing good data (LSR b0..3=1) for the
first byte, then framing errors on subsequent bytes. At this point the UART seems to be getting
locked in an out-of sync state where every byte produces a framing error until there is a gap in the
data.
Adding an additonal stop bit makes no difference.

This also appears to be dependent on the actual data patterns being sent, although I;ve not managed
to nail this down to a consistent behaviour

Anyone else seen this ?
Or anyone got 1Mbit/sec operation reliably?

An Engineer's Guide to the LPC2100 Series

Hi,

> There is a long gap (a few mS) before the first character in each
> 5kbyte data burst, so it will
> always have time to sync properly on the first byte, and should then
> stay in sync indefinitely (which it does quite happily at lower
baudrates).

Ok. So it should get back into sync, no problem.

> One thing I have subsequently noticed is that at 937500 baud it appears
> to be 100% reliable. As
> 937500 is an exact binary division (/64) of 60MHz, I'm wondering if
> maybe the fractional baudrate
> divider is causing incorrect sampling times.

Sounds plausible.

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
Mike Harrison wrote:
> I've tried using a few different CPU clock rates & baudrates and am starting to think there is an
> issue with using the fractional divisor at high baudrates.
>
> These appear to work reliably :
> PCLKHMHz, baud=1.5M (baud=PCLK/32) works (U0DLL=2.U0FDR=0x10),
> PCLKHMHz,baudu0K (baud=PCLK/64) works (U0DLL=2,U0FDR=0x11)
> PCLK`MHz, baud7500 (baud=PCLK/64) works (U0DLL=2,U0FDR=0x11)
> (can't generate data to test 60M/32)
>
> These don't :
> PCLKHMHz,baud=1M (baud=PCLK/48) (U0DLL=2,U0FDR=0x21
> PCLKHMHz, baud=1.2M (baud=PCLK/50) U0DLL=2,U0FDR=0x41
> PCLK`MHz, baud=1.5M (baud=PCLK/48) U0DLL=2,U0FDR=0x41
> PCLKHMHz, baud0K (baud=PCLK/60) U0DLL=2,U0FDR=0x87
> PCLK`MHz, baud=1M (baud=PCLK/60) U0DLL=2,U0FDR=0x87
>
Hi Mike,

I agree with you that this would seem the case but I will add another odd twist.

I recently was trying to get a 2148 using UART1 communicating at 3.75M baud connected to 3-2103's using UART0. The 2148 was running at 60MHz and the 2103's was running at 70MHz. I found that we where getting 0xFF characters (sometimes) between characters being sent from the 2148 to the 2103s. I slowed the 2103 processor clocks to 60MHz and everything ran correctly after that from 9600 to 3.75M baud.

Now here is the twist. I originally designed the interface for SPI and SSP so I can get faster communications. I was getting misc. characters interspersed with the data (just like the above description). That was why I moved to the standard serial communications in the first place. Now I tried experiments with SCLK of 500KHz to 10MHz and the result was always the same. Again the 2148 was running at 60MHz and the 2103's at 70MHz. Later when I get some time I will revisit this SPI and SSP modes with both processors running at 60MHz to see if the SPI data corruption disappears.

I worked with NXP to try to resolve this but there was no immediate answers to my questions and I was pressed for time. Just thought you should know that this is not strictly a UART problem.

regards,
Charles
I've tried using a few different CPU clock rates & baudrates and am starting to think there is an
issue with using the fractional divisor at high baudrates.

These appear to work reliably :
PCLKHMHz, baud=1.5M (baud=PCLK/32) works (U0DLL=2.U0FDR=0x10),
PCLKHMHz,baudu0K (baud=PCLK/64) works (U0DLL=2,U0FDR=0x11)
PCLK`MHz, baud7500 (baud=PCLK/64) works (U0DLL=2,U0FDR=0x11)
(can't generate data to test 60M/32)

These don't :
PCLKHMHz,baud=1M (baud=PCLK/48) (U0DLL=2,U0FDR=0x21
PCLKHMHz, baud=1.2M (baud=PCLK/50) U0DLL=2,U0FDR=0x41
PCLK`MHz, baud=1.5M (baud=PCLK/48) U0DLL=2,U0FDR=0x41
PCLKHMHz, baud0K (baud=PCLK/60) U0DLL=2,U0FDR=0x87
PCLK`MHz, baud=1M (baud=PCLK/60) U0DLL=2,U0FDR=0x87