espressif
UART: When using serial port 0 at a baud rate of 3M, transmitting garbled files larger than 5M will cause the serial port to fail (IDFGH-15281)
Answers checklist.
- [x] I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
- [x] I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
- [x] I have searched the issue tracker for a similar issue and not found a similar issue.
IDF version.
5.3
Espressif SoC revision.
ESP32
Operating System used.
Windows
How did you build your project?
Eclipse IDE
If you are using Windows, please specify command line type.
None
Development Kit.
ESP32
Power Supply used.
USB
What is the expected behavior?
Background: ESP32 enables AP, creates a TCP server, and then the computer connects to the server. Files are sent via TCP, and ESP32 writes the received TCP characters intact using uart_write.The serial port started IRAM Pass the data received by the TCP server into the serial port intact。
What is the actual behavior?
Packet loss + garbled text。 100% reproduction
Steps to reproduce.
1、At a baud rate of 3M, normal log files (13M in size) were transferred. After the transfer was completed, no packets were lost and the data remained stable。 2、The environment remained unchanged. When I converted the file into a compiled elf file, I found that the transmission was over 5M, the serial port lost packets, and all subsequent logs were garbled. After comparison, the garbled data was the same as the elf file I sent with lost packets. 3、The fifo, interrupt threshold and memory application have been modified, but none of them worked
Debug Logs.
no
Diagnostic report archive.
No response
More Information.
No response
@736676938 Long UART transmissions at high speeds are vulnerable to clock drift, cumulative timing drift could cause the receiver to sample at the wrong points. If you experience packet loss or garbling over large files, especially with binary data, it's very likely due to baud rate mismatch and lack of idle time for realignment.
Can you call uart_get_baudrate to check what is the actual baud rate set for UART port 0? It might be slightly off from 3M. And try to use the exact baud rate value to decode. If this doesn't help, then you probably need to send shorter frames, with short gaps or checksums to let the receiver realign.
If it works with ASCII/text data but loses chunks of binary, the problem may be in the way you transfer data from TCP to the UART; specifically when determining the length of data to copy over.
If it works with ASCII/text data but loses chunks of binary, the problem may be in the way you transfer data from TCP to the UART; specifically when determining the length of data to copy over. I have tested that the character length received by TCP is the same as the character length I sent. The problem I can confirm now is that there is packet loss when calling the esp_uart_write() interface. Doubt whether it is related to DMA
@736676938 Long UART transmissions at high speeds are vulnerable to clock drift, cumulative timing drift could cause the receiver to sample at the wrong points. If you experience packet loss or garbling over large files, especially with binary data, it's very likely due to baud rate mismatch and lack of idle time for realignment.
Can you call
uart_get_baudrateto check what is the actual baud rate set for UART port 0? It might be slightly off from 3M. And try to use the exact baud rate value to decode. If this doesn't help, then you probably need to send shorter frames, with short gaps or checksums to let the receiver realign.
When I use normal text files, there is no packet loss. I suspect it is a problem with the fifo counting within your company. When I send invisible characters with a length greater than 20,000, I find that packet loss occurs, and after I send 1,000 visible characters subsequently, only the last 200 are the visible characters I sent. From this, it can be known that there is a problem with the count value of the fifo.
I haven't heard of any transmission packet loss issue before. Can you check the TX line with a logic analyzer, see if it is really missing a chunk of data? Maybe you can simplify the usage, and create a minimal reproducible program? The TCP part can be eliminated, the compiled elf file can be an embedded file in the chip, and use UART to send directly. I would like to see how you initialize the UART driver, and whether you are using TX ring buffer? And what if you set TX ring buffer size to 0 to use FIFO only, will there be any packet loss?
I haven't heard of any transmission packet loss issue before. Can you check the TX line with a logic analyzer, see if it is really missing a chunk of data? Maybe you can simplify the usage, and create a minimal reproducible program? The TCP part can be eliminated, the compiled elf file can be an embedded file in the chip, and use UART to send directly. I would like to see how you initialize the UART driver, and whether you are using TX ring buffer? And what if you set TX ring buffer size to 0 to use FIFO only, will there be any packet loss? Ok. I'll spare some time to try and see if it can be reproduced
I haven't heard of any transmission packet loss issue before. Can you check the TX line with a logic analyzer, see if it is really missing a chunk of data? Maybe you can simplify the usage, and create a minimal reproducible program? The TCP part can be eliminated, the compiled elf file can be an embedded file in the chip, and use UART to send directly. I would like to see how you initialize the UART driver, and whether you are using TX ring buffer? And what if you set TX ring buffer size to 0 to use FIFO only, will there be any packet loss? When sending 30K data at a time, a packet loss occurred. The source code is as follows： uart_echo.zip
I haven't heard of any transmission packet loss issue before. Can you check the TX line with a logic analyzer, see if it is really missing a chunk of data? Maybe you can simplify the usage, and create a minimal reproducible program? The TCP part can be eliminated, the compiled elf file can be an embedded file in the chip, and use UART to send directly. I would like to see how you initialize the UART driver, and whether you are using TX ring buffer? And what if you set TX ring buffer size to 0 to use FIFO only, will there be any packet loss?
hello, could you help take a look at this problem?
@736676938 Ok, I think I know what is wrong. I reproduced the issue with our devkit, but if I directly connect the TX pin to a logic analyzer, it shows no missing data, this indicates that UART itself works fine. I believe you are also using an ESP32 devkit with a USB to UART bridge chip, such as CP2102, so that you can read the UART port on your computer. However, according to the datasheet of CP2102, it only supports baud rate up to 1Mbps. That's why it losses packet. I tried with connecting to a better USB to UART bridge chip (our ESP-prog board), no missing packet anymore. You should also find a better USB to UART bridge chip that can meet your high baud rate requirement.
Thanks for reporting, will close due to inactivity, feel free to reopen.
