UART speeds above 460800 on ESP32 no longer functional since v3.0.

[ewpa]

Board

ESP32 Dev Module

Device Description

ESP32-WROOM-32E on simple board.

Hardware Configuration

Using hardware serial 2 UART at 3.3V, pins 16 and 17.

Version

v3.0.5

IDE Name

arduino-cli

Operating System

GNU/Linux

Flash frequency

80MHz

PSRAM enabled

no

Upload speed

115200

Description

Hardware serial 2 BAUD rates of 921600 and above were usable on ESP32 Arduino 2.0.17. On 3.0 and 3.1 they are no longer usable, garbage is seen.

Sketch

HardwareSerial hs0(2);
hs0.begin(intendedBaud, SERIAL_8N1, RX2, TX2);

Debug Message

Garbage.

Other Steps to Reproduce

Appears related to espressif/esp-idf PR#8572 reported by b1ackviking. I have created a PR with this fix and it resolves this regression.

I have checked existing issues, online documentation and the Troubleshooting Guide

• I confirm I have checked existing issues, online documentation and Troubleshooting guide.

[SuGlider]

@ewpa - I guess that this issue is related to the PR #11025
I have tested this sketch, similar to the one in this issue.
It works fine. No issues.

HardwareSerial hs0(2);

// ESP32 with Arduino Core 3.1.3
void setup() {
  // Starts console (UART0 - Serial Monior)
  Serial.begin(115200);
  // starts UART2 at 921,600 on RX2(18) and TX2(19)
  hs0.begin(921600, SERIAL_8N1, 18, 19);
}

void loop() {
  // using Putty for connecting to Serial2 
  // CH341 USB-UART converter on pins 18 (TXD) and 19 (RXD) - cross connected
  // This will echo any character typed on Putty back and into console (Serial Monitor)
  if (hs0.available()) {
    char c = hs0.read();
    Serial.write(c);
    hs0.write(c);
  }
}

[ewpa]

Hi @SuGlider, based on your PR comments I traced the calls where the clocks were determined. In my code, this was being executed just once, hence the wrong clock was selected for higher BAUD rates, e.g.

  Serial.begin(9600);
  // starts UART2 at 921,600 on RX2(18) and TX2(19)
  hs0.begin(921600, SERIAL_8N1, 18, 19);

This is a change in behavior from 2.0, and my PR did inadvertently fix it, however the fix/workaround was simple adding Serial.end before subsequent faster Serial.begins:

  Serial.begin(9600);
  // starts UART2 at 921,600 on RX2(18) and TX2(19)
  hs0.end();
  hs0.begin(921600, SERIAL_8N1, 18, 19);

So I am happy to withdraw PR#11025 and close this issue. I am not certain on the intended behavior of multiple begins in the Arduino platform.

[SuGlider]

@ewpa - Using Arduino Core 3.1.3, all these use cases shall work correctly, for any ESP32 UART port (Serial, Serial1, Serial2) :
Examples using Serial2 (UART2):

   Serial2.begin(921600); // it shall start with 8N1, default RX2/TX2 pins at 921600
   Serial2.setPins(anyRX2pin, anyTX2pin); // keeps the same baudrate and just changes the pins

   Serial2.begin(9600, SERIAL_8N1, anyRX2pin, anyTX2pin);
   Serial2.begin(921600); // it shall keep 8N1, the same previous RX2/TX2 pins and just changes the baudrate

   Serial2.begin(9600, SERIAL_8N1, anyRX2pin, anyTX2pin);
   Serial2.updateBaudRate(921600); // it shall keep 8N1, the same previous RX2/TX2 pins and just changes the baudrate

Let me know if you have any question or any other use case that may cause an error.

[ewpa]

Hi @SuGlider I have not started migration to 3.1 yet since migration to 3.0 is not stable for me and I get watchdog timeouts on 3.1. I did try 3.1.3 and it still requires end() to work. Chip is ESP32-D0WD-V3 (revision v3.0). Maybe there's something else strange in my code for me to unearth. I do use two UARTS concurrently.
Correction: does not need end when using updateBaudRate.

[SuGlider]

Hi @SuGlider I have not started migration to 3.1 yet since migration to 3.0 is not stable for me and I get watchdog timeouts on 3.1. I did try 3.1.3 and it still requires end() to work. Chip is ESP32-D0WD-V3 (revision v3.0). Maybe there's something else strange in my code for me to unearth. I do use two UARTS concurrently. Correction: does not need end when using updateBaudRate.

@ewpa - please help me with a simple sketch that demonstrates the issue using 3.1.3. I'll debug it and fix it.

[SuGlider]

Do you share my belief that we could resolve/close both this issue and PR #11025 while we wait for new information from your migration project?

[ewpa]

Agreed. I can raise a new issue when ready. It will take some time since it makes heavy use of concurrent tasks and encrypted communications.