UART Communication problems at 921600

[LukeSkyWire]

Hi All,

Has anyone been able to get the UART to communicate reliably at 921600?

I am using the ESP-WROOM DevKitC V2.

I am using UART_NUM_2 on GPIO_16 and GPIO_17.

My Saleae Logic analyzer indicates framing errors on the data out of the UART.

I print out the result of uart_get_baudrate() which is 941176.
However, the logic analyzer still identifies framing issues with the baudrate defined as 941176.

At 115200 there are no issues reported from the logic analyzer and it communicates with my micro with no problem.

Has anyone been able to use the UART at 921600?

Thank you for your help in advance.

[ESP_Angus]

Hi LukeSkyWire,

The UART baud rate is an integer divider from the APB clock frequency (80MHz)[*] times 16, so 941176 is the closest evenly divisible rate. You could also try 1 megabaud (1000000, a very easy value to divide to) and see how this works.

How is your analog signal integrity? 1MHz is getting to the kind of speed where parastic capacitance & inductance begins to matter, from things like long cables and breadboards and ground paths. Breadboards in particular are great at ruining signal integrity...


[*] For the record, this is true unless the UART is specifically configured to use the TICK clock source.

[LukeSkyWire]

Hi ESP Angus,

The signal integrity looks ok.
I'm modded our current product with the ESP32 WROOM so that it sits over our current WIFI module, while we hold our WIFI module in reset.

Our current WIFI module has received an EOL notice and are taking the opportunity to move away from those line of products.
What we are trying to achieve is the replacement of the WIFI module without changing our driver to allow for backwards compatibility with products already in the field.

I'd appreciate it if you could point me to some documentation relating to the use of the Tick clock as a source for the uart driver.

[WiFive]

https://github.com/espressif/esp-idf/bl ... art.h#L110

But 16mhz/17 is still 941176, 2.1% error

[ESP_Angus]

The signal integrity looks ok.

Do you have some oscilloscope traces that you can share?

I'd appreciate it if you could point me to some documentation relating to the use of the Tick clock as a source for the uart driver.

Sorry, I should have been more specific. The tick clock is slower, so it won't help in this case. But it's controlled by the configuration field linked by WiFive.

[LukeSkyWire]

Hi ESP_Angus

I've made peace with having to change my driver.

Below is a picture of the trace at 1Mbps.

UART.PNG (19.21 KiB) Viewed 23322 times

What I have noticed however is if I send 1400 bytes the uart_read_bytes returns a value in the range of 1390.
If I send 600 bytes I get a len of approx 596.

I use the following to read those bytes.
int len = uart_read_bytes(uart_num, (uint8_t *)&recvfrmMicro[0], sizeof(recvfrmMicro), 10 / portTICK_RATE_MS);

I suspect that the ISR cannot keep up.
Is it possible to use DMA on the UART?

EDIT:
The reason I believe the interrupt service routine can't keep up is that at at 500kbps the len equals what was sent.

Regards

[ESP_Angus]

Glad you solved the framing issue. What was the root cause?

We run an automated test on our AT command firmware (which uses the UART driver) to ensure no loss of data at 2Mbps. So in theory the UART driver can keep up. Is it possible there's another task or a lot of interrupt activity on the same CPU as the UART receive, which may be starving it of resources?

EDIT: Did you call uart_driver_install()? What rx buffer size was specified?

Angus

[LukeSkyWire]

Hi ESP_Angus

I think the root cause is as you mentioned; I the interrupts for the send and receive socket server task is most probably on the same CPU. As a result slowing the baud rate worked.

I've had a similar issue on our main processor before and we used DMA instead of an interrupt driven driver to solve it.
That's why I'm interested to find out if DMA is available on the UART?

I did call the uart_driver_install(). The RX buffer size was set at 4096.
Do you have a recommended size for that speed (1Mbps)?

I'm not 100% sure how to allocate the tasks to the different processors yet.
I've been looking into replacing our current serial 2 wifi module with the ESP32 for about a week now just to ensure it can work.
In that time we've been able to get our comms up and communicating with our devices, even at a reduced speed, so I'm happy.
I just need to get the higher baudrate working now.
I will definitely have a look at your AT command firmware.

Thank you for your help.

[ESP_Angus]

I think the root cause is as you mentioned; I the interrupts for the send and receive socket server task is most probably on the same CPU. As a result slowing the baud rate worked.


I've had a similar issue on our main processor before and we used DMA instead of an interrupt driven driver to solve it.
That's why I'm interested to find out if DMA is available on the UART?

There's hardware support for a UART DMA mode ("UHCI") but unfortunately the only implementation is currently for Bluetooth HCI.

I did call the uart_driver_install(). The RX buffer size was set at 4096.
Do you have a recommended size for that speed (1Mbps)?

It depends on how fast you think your task can call uart_read_bytes(). The ISR will fill the buffer and uart_read_bytes() will empty it.

In other words: If the ISR is delayed, the 128 byte hardware FIFO overflows. If the task is delayed, the RX buffer overflows. If you're losing bytes in a 1310 byte transfer with a 4096 byte buffer then the problem is in the ISR, though.

I'm not 100% sure how to allocate the tasks to the different processors yet.

You can use xTaskCreatePinnedToCore() - see https://espressif-docs.readthedocs-host ... k-creation

If you create a task pinned to CPU 1, and then call uart_driver_install() from this task, then both the ISR and the task will be on CPU 1 and should be isolated from WiFi activity.

[Crypth]

Glad you solved the framing issue. What was the root cause?

We run an automated test on our AT command firmware (which uses the UART driver) to ensure no loss of data at 2Mbps. So in theory the UART driver can keep up. Is it possible there's another task or a lot of interrupt activity on the same CPU as the UART receive, which may be starving it of resources?

EDIT: Did you call uart_driver_install()? What rx buffer size was specified?

Angus

@Angus
We've been running tests on the ESP-WROOM DevKitC V4 and standalone modules using the AT library.
We tried 1.1.3, 1.2 and built our own with IDF on 3.3.
Running the UART in 2MBaud gives us errors, not often, but enough to make it a problem. Lowering the baudrate to 1Mbit helps, but there are still errors. At lower rates it gets better and better. The problem seems to be a missing byte in the receiving end (ESP32), never the other way around, which seems to fit what is said in this discussion.

We built the esp-idf at 240Mhz with the AT lib which also decreases the errors over running it at 80Mhz, but it's still there.
We can't pin the AT library to one CPU since it's closed (right, since we're not the ones calling uart_driver_install()). Perhaps this could be an option?

We're also experiencing that even if we send at maximum rate (wait for the send to be ok) through UDP, we rather end up with an actual ~250Kbps (20-30Kb/s) transfer rate with the AT library. We know the ESP32 is much more capable than this and we've been using both internal antenna and external antenna near an access point, RSSI signal/link speed is not the issue. Are there any deliberate delays here?

The automated test you're running, how is it set up and what sort of data transfers do you get?
Is there any chance the AT library will end up open to the public?

Cheers!