Can I use the UART-to-USB conversion on the LPCXpresso845MAX at baud rates higher than 230400?

[dougturnbow]

I'm connecting to the LPCXpresso845MAX using a micro USB cable, and I'm using TeraTerm on the PC to send/receive UART bytes.

“lpcxpresso845max_hello_world” example program works as-is, unmodified. If I press the reset button on the dev board I get "hello world." on the console: (working)

If I change BOARD_DEBUG_USART_BAUDRATE from 9600 to 115200 in board.h, and change the TeraTerm setting to 115200 baud, when I press the reset button I still get "hello world." on the console.  Same for 230400 baud. (both work)

But if I try 460800 baud or higher, when I press the reset button I get garbage on the console "èoöÌûÏä÷ÏûòûÄ?ù"

I tried using an FTDI cable to perform the UART-to-USB conversion external to the dev board. I connected it to P6 and I can successfully receive the "hello world" message from the dev board that way regardless of the baud rate.

My conclusion is that the UART-to-USB conversion on the dev board only works up to 230400 baud. Is that correct, or is there some way to make it support higher baud rates?

I'm using MCUXpresso IDE v11.5.1 [Build 7266] [2022-04-13]

SDK_2.x_LPCXpresso845MAX is 2.11.0.201911251446 

PC is Windows 10.

[xiangjun_rong]

Hi,

Regarding your question, as you know that each uart bit is sampled 16 times, so the uart module clock is 16*baud-rate, if your baud rate is 460800, the uart clock will be 16*460800=7.3728MHz.

The following figure is the uart clock block diagram, you can configure the FRG module so that the FRG can generate accurate 7.3728MHz clock accurately, or integer times of 7.3728MHz clock accurately. furthermore, external crystal or clock source are preferred, because the clock frequency of external crystal or clock source is more accurate that that of on-chip FRO.

Why two uart modules can not communicate is the mismatch of the driving clock between transmitter and receiver. if the receiver/transmitter use the same driving clock, the communication will always be okay.

For the FTDI usb-uart converter, I suppose the receiver samples the transmitter bit width, and adjust the driving clock, so the baudrate can be higher.

Hope it can help you

BR

XiangJun Rong

[dougturnbow]

OK but in this case, the LPC11U35 on the LPCXpresso845MAX board does the UART to USB conversion, not the LPC84x.

It must have some kind of auto-baud detection because 9600 baud, 115200 baud and 230400 baud all work.

I'm wondering if it can't detect the baud rate at 460800 or can't adjust its UART clock that high with an acceptable degree of accuracy, or it just can't keep up with bytes coming in at 460800 baud.

[frank_m]

> My conclusion is that the UART-to-USB conversion on the dev board only works up to 230400 baud. Is that correct, or is there some way to make it support higher baud rates?

No, this conclusion is based upon assumptions.

The serial data are tunneled through the USB protocol, and the higher the baudrates, the more fragile the timing balance becomes. Most probably, the issue is with the USB driver on the host PC.

In the device manager / properties, there is an "extended settings" dialog for such serial interfaces, where you can change certain USB parameters, like USB package size or delays. 

[dougturnbow]

Thanks Frank.

Please provide more detail on where to find these settings.

Are you talking about the Advanced settings for the COM port in Device Manager?

I've tried adjusting everything I could - turning on/off FIFO buffers and changing the size of the receive and transmit buffers.  None of these seem to affect the issue

I didn't find anything adjustable in the corresponding USB controller device in Device Manager

Am I looking in the right places?

[frank_m]

Yes, that would be the settings you can influence. On my work PC, it looks a bit different - obviously it depends on the driver. (And it's not in English either ...)

But we (me and my work mates) know a few USB-serial adapter one should never attach during Windows boot-up, or else they throw a blue-screen. Which is to demonstrate, such drivers come in different qualities.

I would take a scope and check the signal on the MCU side at mentioned high baudrates, especially the bit timings. If that looks correct, the problem is on the PC hardware/driver side.

I dealt and deal a lot with serial interfaces, lately especially with proprietary serial debug access. None really supports baudrates beyond 115200 bps. And some of the applications on PC side only work correctly with certain USB-serial adapters.

[dougturnbow]

OK.  I guess I'm out of options for using the LPCXpresso845MAX to do the UART-to-USB conversion.

At least for now my workaround is to use an FTDI cable to do the UART-to-USB conversion