ESP32 Dev Module Hardware Serial doesn't work well in 3.0.0 version of boards

[hojanico19]

Board

ESP32 DEV MODULE

Device Description

Hello, I always use ESP32 DEV MODULE for reading Hardware Serial of a sensor
Thanks

Hardware Configuration

Hardware Serial ESP32 DEV MODULE WORK FINE IN 2.0.17 VERSION

Version

v3.0.0

IDE Name

Arduino IDE

Operating System

Windows 10 and Ubuntu 24

Flash frequency

80 and 40

PSRAM enabled

yes

Upload speed

921600

Description

Hello, I always use ESP32 DEV MODULE for reading Hardware Serial of a sensor, but I've actualizaed to 3.0.0 version of boards, and this doesn't work anymore. When I downgrade to 2.0.17 this work completely. So, for now I will use board version 2.0.17. If yo need that I test that issue ask me, for me there is no problem.

Thanks

Sketch

This is private of my company

Debug Message

Rean wrong hexadecimal

Other Steps to Reproduce

No response

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

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

[SuGlider]

@hojanico19 - In order to investigate this issue, we need more information about how to reproduce such problem. One good way to allow us to assist you would be by providing a basic sketch that could be used to see the issue and test a possible fix.

[SuGlider]

Hello, I always use ESP32 DEV MODULE for reading Hardware Serial of a sensor

Please specify the sensor. Is there any open Library that we can use to reproduce the issue?

If yo need that I test that issue ask me, for me there is no problem.

Please provide a minimum Arduino sketch that could be used to reproduce the issue.
We don't need access to your private code, just a simple minimum sketch that can be used to debug the problem.

[hojanico19]

I read directly de hexadecimal and then I calculate the response. The ESP32 only read the serial info, when I use 3.0.0 the hexadecimal is wrong. I can't share more info because my company restrict it.

But you can reply it sending hexadecimal info since a device with 9600 bps and receive it by esp32, then verify that is that is correct. The rate of info es ten hexadecimal per 200 millisenconds

[SuGlider]

Thanks for the explanation... but it is very hard to be able to reproduce such issue.
Please take some time to create (and post here) a basic and simple Arduino Sketch that could be used to replicate the problem.

Otherwise we can't help it.

[hojanico19]

I've reproduced the error. I did this:

1. I used two ESP32 WROOM, in this case ESP32 "A" will be a ESP32 that send messages by serial and ESP32 "B" will recieve it

2. The code of ESP32 A is:

HardwareSerial serial(2); 
void setup() {
serial.begin(9600);
Serial.begin(9600);
}

void loop() {
Serial.println("HOLA");
serial.write("HOLA\n");
delay(1000);
}

3. The code of ESP32 B is:

HardwareSerial serial(2);

void setup() {
Serial.begin(9600);
serial.begin(9600);
Serial.println("Started");
}

void loop() {
while (serial.available() > 0) {
        String value=serial.readStringUntil('\n');
        Serial.println(value);
    }
delay(1000);
}

4. In both of them I've used basic serial begin, because my original sensor send info by serial using 9600 bps, data bit 8, no parity and stop bit 1. Also, I've used arduino IDE for programming the code.

5. ELectronics:
   5.1- TX2 of send board to RX2 of recive board
   5.2- GND to GND

6. Results:
   6.1- When I programmed both of them with 2.0.17 boards version: IT WORKS!
   6.2- When I programmed A with 3.0.0 and B with 2.0.17: IT FAILS :(
   6.3- When I programmed A with 2.0.17 and B with 3.0.0: IT FAILS :(
   6.4- When I programed both of them with 3.0.0 boards version: IT FAILS :(

7. Resume:
   When I use 3.0.0 board version, serial communication fails.

[SuGlider]

Thank you, @hojanico19 - I'll investigate this issue and post here the findings.

[xopxe]

I am seeing the same with ESP32 Sparkfun Thing boards.
When running with 3.0.0 and 3.0.1, a basic sketch that prints through 9600 8N1 serial, I get the bytes mangled. Writing, say, "AAAAA," will get 5 bytes through, and they'll always be the same 5 bytes. But they won't be the five As nor equal bytes, but all over the place. It will be the same random 5-byte long string after resetting and reflashing.
It Happens through Serial1 and Serial2.

I can record tests if needed.

[me-no-dev]

@xopxe ESP32 Sparkfun Thing boards use 26MHz crystal, which is not supported in Arduino starting with v3. There is a workaround here: #9837

[xopxe]

@me-no-dev Thanks, the workaround worked for us. I understand this probably will never be fixed for these boards? Just to know how to deploy the workaround, we have several of these boards around with users.

[me-no-dev]

@xopxe we do not plan support yet, though we might add it as board option for those that have it (like Sparkfun Thing) in the future. Depends on how many people are affected. It would still use that workaround if we do, so you are safe to start using it

[me-no-dev]

Created PR with support for SparkFun ESP32 Thing: #9844

[hojanico19]

@SuGlider Do you have news about it? @me-no-dev has closed this post with another post that is not the same, 'cause this post is for Espressif ESP32

[xopxe]

With the workaround, I'm seeing weird behavior from RTOS timers. I can't pinpoint much because I'm using through a rather involved firmware (micro-ros). But the symptoms are that I have two timers, at 5Hz and 50Hz, triggering at around 2Hz (tough with a big variation),
2.0.13 behaves correctly, also when the workaround is installed.

[SuGlider]

@SuGlider Do you have news about it? @me-no-dev has closed this post with another post that is not the same, 'cause this post is for Espressif ESP32

I have reopen it. I'll investigate it further. I'll post here the fndings.

[xopxe]

Perhaps related: I have an esp-idf project that has been maintained since 2018 and at some point (last year?), I had to start manually setting the "Main XTAL" setting at 26MHz in menuconfig.

[me-no-dev]

Generally the best solution is to have separate libs for 26MHz, but that is really too much. There are probably places where XTAL freq is not taken at runtime, but rather by the preprocessor and now they are causing some issues