Corruption on Serial2 after changing baud rate

[Edgs]

Hardware:

Board: DOIT ESP32 DEVKIT V1
Core Installation/update date: 10/Nov/2017
IDE name: Arduino IDE
Flash Frequency: 80Mhz
Upload Speed: 921600

Description:

HardwareSerial device sends some incorrect characters after changing baudrate.

Serial2 is started at 115200 baud. Write works fine.
Serial2 has baud rate changed to 9600 with a second .begin()
Some .write() characters are then incorrect. It appears to work correctly if that first character is not sent at 115200.
If I send more than 4 characters in sequence like this, it seems to always be some characters at the beginning or end which are affected.

Character sequence should be:
[at 115200]
0x55
[at 9600]
0x01 0x02 0x03 0x04
0x01 0x02 0x03 0x04
etc...

Instead it is:
[at 115200]
0x55
[at 9600]
0xf3 0x03 0x04 0x91
0x02 0x03 0x04 0x45
0x4a 0x03 0x04 0x11
0x73 0x03 0x04 0x1e
etc...finally repeating:
0x02 0x03 0x04 0x01
etc...

Sketch:

#include <Arduino.h>
HardwareSerial SerialGPS(2);

void setup() {
  Serial.begin(115200); // program/debug port
  Serial.println("Starting...");

// start at 115200
  SerialGPS.begin(115200, SERIAL_8N1, 15, 5);
  SerialGPS.write(0x55);
  delay(1000);
  SerialGPS.end();            // < doesn't change anything if not present

// switch to 9600
  SerialGPS.begin(9600, SERIAL_8N1, 15, 5);
}

void loop() {
    SerialGPS.write(0x01);
    SerialGPS.write(0x02);
    SerialGPS.write(0x03);
    SerialGPS.write(0x04);
    delay(1000);
}

[stickbreaker]

This is a recently discovered problem, The UART hardware flush signal on UART2 is cross connected into UART1, when it is activated, bad things happen. There is a conversation on IDF about this. The current work around is to manually drain the fifos by reading and NEVER activating uartFlush()

[TW#16347] Calling uart_flush(2) corrupts data thereafter

BUT currently Serial.begin() includes a call to uartFlush() in esp32-hal-uart.c

Chuck.

[jestebanes]

Hi, I try to solve this issue implementing a change_baud function into the esp32-hal-uart.c and calling from HardwareSerial.cpp

// esp32-hal-uart.c
void uartChangeBaudRate(uint8_t uart_nr, uint32_t baudrate)
{
if(uart_nr > 2) {
return; //Not return NULL
}
uart_t* uart = &_uart_bus_array[uart_nr];
uartSetBaudRate(uart, baudrate);
}

But with the latest library updates, it stopping to work. Maybe uartSetBaudRate now calls to flush.
If there is a solution in esp-idf, please translate to Arduino as soon as possible

Thanks

[Vorms]

Hello,
I am very concerned with issue.
Is that any workarround ?
I definitively need a patch !
Thanks for your help
Best regards
Thierry
vormsty@gmail.com

[jestebanes]

Hello @Vorms, I made a change in the implementation of uartFlush to avoid the hardware reset of the FIFO. For me, this change wasn't enough, because when I update the software via OTA the UART2 stops to work.
Finally, I change the UART2 for UART1 using the same external pins and that solve my issue, I hope in next hardware revisions of the chip, this trouble will be solved because is a shame that those little failures ruin such an incredible chip.

void uartFlush(uart_t* uart)
{
if(uart == NULL) {
return;
}

UART_MUTEX_LOCK();
while(uart->dev->status.txfifo_cnt && uart->dev->mem_cnt_status.tx_cnt);

// uart->dev->conf0.txfifo_rst = 1;
// uart->dev->conf0.txfifo_rst = 0;

// uart->dev->conf0.rxfifo_rst = 1;
// uart->dev->conf0.rxfifo_rst = 0;
uint8_t c;
while(uart->dev->status.rxfifo_cnt && uart->dev->mem_cnt_status.rx_cnt){
READ_PERI_REG(UART_FIFO_REG(uart->num));
}
while(uxQueueMessagesWaiting(uart->queue)){
xQueueReceive(uart->queue, &c, 0);
}

UART_MUTEX_UNLOCK();

}

[Vorms]

Hello I made some test this morning about uart's, changing GPIO pins. I confirm the problem exist with any pins. I see if the uart2 is initialised before the uart1, when I initialise the uart 1 and test the availability of the uart1: MP3Player.begin(9600, SERIAL_8N1, MP3PLAYER_RX, MP3PLAYER_TX); if (debug){ Serial.print("UART available: "); if (MP3Player.available()){ Serial.println("true"); } else { Serial.println("false"); } } The response is false !!!¨ Best regards Thierry 2018-01-05 19:13 GMT-05:00 jestebanes <notifications@github.com>:

…

Hello @Vorms <https://github.com/vorms>, I made a change in the implementation of uartFlush to avoid the hardware reset of the FIFO. For me, this change wasn't enough, because when I update the software via OTA the UART2 stops to work. Finally, I change the UART2 for UART1 using the same external pins and that solve my issue, I hope in next hardware revisions of the chip, this trouble will be solved because is a shame that those little failures ruin such an incredible chip. void uartFlush(uart_t* uart) { if(uart == NULL) { return; } UART_MUTEX_LOCK(); while(uart->dev->status.txfifo_cnt && uart->dev->mem_cnt_status.tx_cnt); // uart->dev->conf0.txfifo_rst = 1; // uart->dev->conf0.txfifo_rst = 0; // uart->dev->conf0.rxfifo_rst = 1; // uart->dev->conf0.rxfifo_rst = 0; uint8_t c; while(uart->dev->status.rxfifo_cnt && uart->dev->mem_cnt_status.rx_cnt){ READ_PERI_REG(UART_FIFO_REG(uart->num)); } while(uxQueueMessagesWaiting(uart->queue)){ xQueueReceive(uart->queue, &c, 0); } UART_MUTEX_UNLOCK(); } — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#854 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AD0B8YOfzoPy0Rpou4fGlaHHdzl7lLDuks5tHrqOgaJpZM4QlEWe> .

-- Thierry Vorms Québec Canada

[jestebanes]

Did you try to change the uartFlush function in esp32-hal-uart.c?

[9a4gl]

Same problem here. Uploading data to Nextion display over UART2, in process Serial2.begin is called with different baudrates and UART2 it stops working :(

[everslick]

I think there have been some fixes lately. Is this issue still relevant for latest master?

[nelfata]

Is there any resolution on this issue?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

[stale]

This stale issue has been automatically closed. Thank you for your contributions.