UART Communication Delays and Data Loss #10420
Comments
|
@mightChamp - The issue is related only to Core 3.1.0-RC1? Does it also happen with Core 3.0.5? |
SuGlider
added
Peripheral: UART
Priority: High 🗻
SuGlider
moved this from Todo
to Under investigation
in Arduino ESP32 Core Project Roadmap
|
This sounds related to #10397 The evidence is that whenever In Arduino Core 1.0.6, the UART driver was local one, faster and way more efficient. |
|
@mightChamp - Could you please check if PR #10428 solves this issue too? |
|
We have tested the fix from PR #10428, but unfortunately, we are still facing the same issue. This issue is currently blocking our development progress, and we would greatly appreciate an estimate of how long it might take to investigate or resolve this. If there are any further tests or adjustments we could try, we are ready to assist. |
|
@mightChamp - based on what @lbernstone wrote, there are a few new methods to deal with UART that were not available in 1.0.6.
|
|
I'll build a Python script + the sketch example that is here listed to find out more about the issue. |
Despite testing all examples, we encountered significant performance degradation, and also faces missing data bytes and delay issue. |
Please elaborate more about "significant performance degradation", "missing data bytes" and "delay issue". You can count on me for fixing it ASAP. Thanks! |
|
We are experiencing a delay issue that creates the illusion of missing bytes due to timeout. Also PR #10429, reduces this delay, but still face some delay, as compared to V1.0.6. Our project is quite large, using 1.6 MB of Flash and 35% of RAM, with two additional tasks running. The code works perfectly in v1.0.6, but we are looking to upgrade to the latest SDK. Due to the size and complexity of the code, providing a simplified version for testing is challenging. |
|
@mightChamp - Could you please test it using this sketch: |
|
I had the same issue. This works well on BSP version 3.0.3. The println function will then write the value of 60. And the connection will not loose data anymore. For the latest BSP version now (V 3.1.3), the value of 60 wouldn't work anymore. Then the println function will also return random numbers, (and the connection will loose data). Please can anyone repair this? |
|
Update: |
|
The above works for esp32 V3.0.3. |
|
@EricHarbers Could you test with core 3.2.0-rc2? |
Jason2866
removed
the
breaking-change 💥
|
@SuGlider Can you have a look, if the issue is still in 3.2.0-rc2 it would be good if it could be fixed before release of 3.2.0 |
|
@Jason2866 I've checked with core 3.2.0-RC2, but the the problem is still there. The version again does not read stable block sizes. |
|
@Jason2866 A problem will also be, that you have to always call the onReceiveError() function to install the error callback function. Even if the function is empty. Not calling the onReceiveError() function lets the application crash. |
|
@EricHarbers Thx for the testing. SuGlider is the expert and will have for sure a look. I am only helping a bit to track the issues. |
|
I have tested it. It works fine with Arduino Core 3.1.3 or using master branch. There is no data loss. 100 bytes test can use this input: void setup() {
Serial.begin(115200); // UART initialized at 115200 baud rate
}
void loop() {
if (Serial.available()) {
Serial.println("got a data strem");
String data = Serial.readString();
Serial.printf("\r\nRead %d bytes.\r\n", data.length());
uint32_t i = 0;
uint32_t dataLen = data.length();
while (i < dataLen) {
int r = dataLen > 50 ? 50 : dataLen;
for (int j = 0; j < r; j++) {
Serial.print((char) *(data.c_str() + i + j));
}
i += r;
Serial.println();
}
}
}Output: |
|
#define BAUD_RATE 230400 void receiveSerial(); uint8_t ReceiveBuffer[1024]; void setup() { Serial.begin(uartBaudrate); // the 2 lines below will work properly for esp32 BSP V3.0.3 Serial.setRxTimeout(50); // max value 101 on core 3.0.3 Serial.onReceive(bluetooth_receiveSerial); // bluetooth_receiveSerial void receiveSerial() { while ((len = Serial.read(ReceiveBuffer, sizeof(ReceiveBuffer))) > 0) { void receiveErrorSerial(hardwareSerial_error_t e) { void loop() { //////////////////////// The 120 is the 120 bytes set in the setRxFIFOFull function With core 3.1.3 and newer, the output will be random, eg: Most values will be very small releated to the setting of 120 set with the setRxFIFOFull function. It seems that the Serial.setRxTimeout() function will not work properly. |
|
The issue is that Any ISR shall do the minimal necessary to just get the UART data. It is necessary to change the code. |
|
This issue is cross related to #10314 (comment) |
|
@SuGlider How can you explain that the code with V3.0.3 and below will receive nice data chunks of 120 bytes, set by the setRxFIFOFull function, and not loose data at any time but for V3.1.3 it will read random length blocks, short and very long, and loose data. But, i've a workaround for this problem: I'll use V3.0.3 and everything works fine. |
|
@SuGlider I've test it with a disabled BT write call, and it will output the same random lengthes, for V3.1.3 |
|
@SuGlider I've now called my receiveSerial() function, which calls the BT write(), from within the loop() function, and it works the same for V3.1.3. It also looses data regularly. |
|
@SuGlider There are 2 ways of using a UART: I can understand that your engineers have decided to change the way of processing between V3.0.3 and V3.1.3, from type 2 to type 1 because the latency is lower. Can't you make something in your software, maybe Serial.setRxFIFOFull(0), so that someone can choose between both options? |
|
@EricHarbers - I'd like to make a suggestion that may solve the issue you are facing, in case that it applies to your application.
This can be used with In that case, Something like that: #define BAUD_RATE 230400
#define RX_BUFFER_SIZE 1024
void receiveSerial();
void receiveErrorSerial(hardwareSerial_error_t e);
uint8_t ReceiveBuffer[RX_BUFFER_SIZE];
unsigned int uartBaudrate;
void setup() {
// put your setup code here, to run once:
uartBaudrate = BAUD_RATE;
Serial.setRxBufferSize(RX_BUFFER_SIZE * 2);
Serial.begin(uartBaudrate);
Serial1.begin(uartBaudrate, SERIAL_8N1, 26, 27);
// the 2 lines below will work properly for esp32 BSP V3.0.3
// for the version V3.1.3, it will not work at all
Serial.setRxFIFOFull(120);
Serial.setRxTimeout(50); // max value 101 on core 3.0.3
Serial.onReceive(bluetooth_receiveSerial, true); // callback is called only on RX Timeout
Serial.onReceiveError(bluetooth_receiveErrorSerial);
}
void bluetooth_receiveSerial() {
static int col = 0;
size_t len;
// given that the callback is called at the end of the transmission, it will read all data that has arrived into UART
while ((len = Serial.read(ReceiveBuffer, sizeof(ReceiveBuffer))) > 0) {
SerialBT.write(ReceiveBuffer, len);
Serial1.printf("%5u", len);
if (++col == 25) {
Serial1.printf("\r\n");
col = 0;
}
}
}
void bluetooth_receiveErrorSerial(hardwareSerial_error_t e) {
// Serial1.printf("Error %X\r\n", e);
}
void loop() {
// put your main code here, to run repeatedly:
} |
|
@SuGlider This works for me! There is no data loss now. |
|
@EricHarbers Can we consider as solved and close this issue? |
|
@SuGlider I agree with that. |
github-project-automation
bot
moved this from Under investigation
to Done
in Arduino ESP32 Core Project Roadmap
Board
ESP32 Wroom 32E 4MB Flash
Device Description
We are making an Uart Data logger, an external device send uart data, which stored in SD card.
Hardware Configuration
GPIO13- Uart TX, and GPIO14- Uart RX
Uart setup:
Baud Rate: 115200
Flow Control: Disabled
Buffer Size: 4096
Version
latest development Release Candidate (RC-X)
IDE Name
Arduino IDE
Operating System
Windows 11
Flash frequency
80Mhz
PSRAM enabled
no
Upload speed
921600
Description
We are encountering an issue with UART communication on ESP32 where data reception is delayed, and sometimes data is lost. This issue occurs intermittently and was not present in version v1.0.6.
Sketch
Debug Message
Other Steps to Reproduce
Set up UART communication between ESP32 and another device.
Send continuous data streams over UART.
Observe occasional delays and missed data.
I have checked existing issues, online documentation and the Troubleshooting Guide
The text was updated successfully, but these errors were encountered: