ESP32 Arduino Core 3.3.6: Serial.available() not working on ESP32-S3 (works in 3.3.5)

[rvbc1]

Board

ESP32-S3 (N8R2)

Device Description

Dev-board

Hardware Configuration

No, only USB-Serial converter

Version

v3.3.6

Type

Bug

IDE Name

VSCode, platfomrio

Operating System

macos sonoma

Flash frequency

IDK (default)

PSRAM enabled

yes

Upload speed

IDK (default)

Description

I’m experiencing a regression when using Arduino ESP32 core v3.3.6 on an ESP32-S3 (N8R2).

The following minimal sketch works correctly in v3.3.4, but does not work in v3.3.6 (I was not able to test v3.3.5 yet).

Observed behavior
In v3.3.4:
• Incoming UART data is detected correctly.
• Serial.available() returns expected values.
• Echo works as intended.
In v3.3.6:
• Serial.available() always returns 0.
• No incoming data is detected.
• RX appears non-functional.

Additional notes
• UART TX is working correctly:
• Serial.println() outputs data without any issues.
• This looks like a problem specifically related to RX / Serial.available() handling.
• Hardware setup has not changed between versions.
• Board: ESP32-S3 N8R2
• Baud rate: 115200

Expected behavior

Serial.available() should correctly report received bytes on ESP32-S3, same as in Arduino ESP32 core v3.3.4.

Sketch

void setup() {
    Serial.begin(115200);
}

void loop() {
    while (Serial.available()) {
        char inChar = (char)Serial.read();
        Serial.print(inChar);
    }
}

Debug Message

none

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]

I can take a look when I get back from vacation, in February.

Anyway, this issue is not compatible with the CI results over UART, once it is based on reading data.

Please wait 10 days, when I'll be able to get an ESP32 for testing it.

[nomakewan]

Can confirm the exact same issue on our application (Ghostbusters Proton Pack running ESP32-S3N16R8 talking to an external device over UART that is an ESP32-DOWD). Works perfectly fine on 3.3.5, serial data is completely broken on 3.3.6.

[SuGlider]

@rvbc1 - I have tested an ESP32-S3 DevkitC v1.1 using the Arduino Core 3.3.6 with the sketch from this issue.
I used the Arduino Serial Monitor to send data to the RX0 pin.
It worked correctly. This is an ESP32-S3 WROOM-2 SoC (N32R8).

Is your issue related to reading data when directly connected to some device or using the USB CP2102 converter?
Please tell more about the UART0 connection when the issue occurs.

[SuGlider]

@nomakewan

Can confirm the exact same issue on our application (Ghostbusters Proton Pack running ESP32-S3N16R8 talking to an external device over UART that is an ESP32-DOWD). Works perfectly fine on 3.3.5, serial data is completely broken on 3.3.6.

Please provide more information about it. In order to fix the issue, I must replicate it.

---

@rvbc1 @nomakewan

IDF has changed the way RX pin is configured by not pulling up RX pin by default.
Therefore, a possible problem is related to correct RX-TX line pull up with an external resistor or with using the internal resistor by explicitly calling:

// ---- when using begin():
    // pinMode will force enabling the internal pullup resistor (IDF 5.3.2 Change)
    pinMode(RX_Pin, INPUT_PULLUP);
    Serial.begin(115200, SERIAL8_N1, RX_Pin, TX_pin);

// ---- or when using setPins():
    // pinMode will force enabling the internal pullup resistor (IDF 5.3.2 Change)
    pinMode(RX_Pin, INPUT_PULLUP);
    Serial.setPins(RX_Pin);  // set RX_Pin to its UART function after triggering the internal pull-up resistor

#include "driver/uart.h"
...
Serial.begin(115200);
// IDF Call to force RX pin internal pull-up configuration
gpio_set_pull_mode(rx_io_num, GPIO_PULLUP_ONLY);

---

In case that the workaround above works for your projects, please let me know.
We may consider forcing the pull-up internal resistor for the next Arduino Core release.

[nomakewan]

@SuGlider Apologies for the delay; I was out yesterday and only just now returned to my lab. Adding the pinMode line did not mitigate the issue, unfortunately. Here was the code change made, per your above example:

ESP32-DOWD

  pinMode(RXD2, INPUT_PULLUP);
  PackSerial.begin(9600, SERIAL_8N1, RXD2, TXD2);

ESP32-S3

  pinMode(ATTENUATOR_RX_PIN, INPUT_PULLUP);
  AttenuatorSerial.begin(9600, SERIAL_8N1, ATTENUATOR_RX_PIN, ATTENUATOR_TX_PIN);

Same issue where the devices cannot communicate with one another.

Our project uses PlatformIO. You can see our project here, in the 6.1.Dev branch:

ESP32-DOWD: https://github.com/gpstar81/GPStar-proton-pack/tree/v6.1.Dev/source/Attenuator
ESP32-S3: https://github.com/gpstar81/GPStar-proton-pack/tree/v6.1.Dev/source/ProtonPack

The ESP32-DOWD device uses the builtin RXD2/TXD2 pins (I believe these are pins 16 and 17).
The ESP32-S3 device connects to the ESP32-DOWD using pins 44 (RX) and 43 (TX).

The moment I load a binary built with 3.3.6 onto the ESP32-S3, the serial comms fail. If I load a binary built with 3.3.5 onto the ESP32-S3 but have a binary built with 3.3.6 on the ESP32-DOWD, the serial data works. This suggests that whatever this problem is, it is specific to the UART on the ESP32-S3.

[SuGlider]

@nomakewan - The default pins for ESP32 RXD2 and TXD2 have changed to 4 and 25, instead of 16 and 17.
Is it possible that it could be the source of the problem?

https://github.com/SuGlider/arduino-esp32/blob/master/cores/esp32/HardwareSerial.h

#if SOC_UART_HP_NUM > 2
#ifndef RX2
#if CONFIG_IDF_TARGET_ESP32
#define RX2 (gpio_num_t)4
#elif CONFIG_IDF_TARGET_ESP32S3
#define RX2 (gpio_num_t)19
#endif
#endif

#ifndef TX2
#if CONFIG_IDF_TARGET_ESP32
#define TX2 (gpio_num_t)25
#elif CONFIG_IDF_TARGET_ESP32S3
#define TX2 (gpio_num_t)20
#endif
#endif
#endif /* SOC_UART_HP_NUM > 2 */

[SuGlider]

Please nevermind about the comment above. I see that there is a Serial.h file that defines RXD2 and TXD2 pins.
I'll try to replicate the issue using the S3 and an ESP32 SoC here.

[I-Connect]

Hi, same issue here; not working serial on 3.3.6 (does work on 3.3.5)
But we only experience it on Serial2, Serial1 does work

Running on:
ESP32-WROOM-32UE-N16

Calling below method results in a working Serial1; we get data from the device (we only use the input here so no tx pin defined)
Serial1.begin(115200, SERIAL_8N1, GPIO_NUM_36, GPIO_NUM_NC);

Calling below method does not result in a working Serial2 on 3.3.6; the gsm module connected cannot be accessed and/or does not respond via Serial.
Serial2.begin(115200, SERIAL_8N1, GPIO_NUM_25, GPIO_NUM_26);

I tried this but it did not fix the issue

pinMode(GPIO_NUM_25, INPUT_PULLUP);
Serial2.begin(115200, SERIAL_8N1, GPIO_NUM_25, GPIO_NUM_26);;

Maybe this helps in troubleshooting

[nomakewan]

On our setup, the ESP32-S3 communicates with the upstream ESP32-DOWD device using UART1 via the assignment HardwareSerial AttenuatorSerial(1); // Associate AttenuatorSerial with UART1. The communication is bidirectional however so it does have both RX and TX. This fails, so by combining your report and mine, perhaps TX on UART1 and RX on UART2 are broken somehow? Or perhaps TX and RX components of the various UARTs on the ESP32-S3 were somehow misallocated?

[nomakewan]

UPDATE: By writing a piece of code that makes an audio cue whenever data from the upstream ESP32-DOWD is received I was able to confirm that indeed, the RX on UART1 on my application is working correctly. The ESP32-S3 is indeed receiving the request to sync from the upstream device, but is apparently not transmitting the response.

I was also able to confirm (by reassigning the transmit function to the other UARTs while leaving the receive on UART1) that this is not an issue with misallocating the TX resource to the wrong UART peripheral. That is, attempting to transmit via UART0 or UART2 does not transmit to the upstream device unexpectedly. So it appears that the TX on UART1 is just dead for some reason.

By then changing the assignment for the upstream device comms to UART2, I was able to confirm that the audio cue does not play, suggesting that indeed RX on UART2 is broken.

I then switched the upstream device to UART0, and bidirectional comms worked perfectly.

Hope this helps!

[nomakewan]

Correction to above: I forgot that the audio board itself was being assigned to UART2 in another header. After moving the audio board to UART0 (to guarantee it would function) and then assigning the comms with the upstream ESP32-DOWD to UART2, I get the same audio cue playing over and over suggesting the request to sync is being received successfully, but the response is not being transmitted correctly. So when the upstream device comms are assigned to either UART1 or UART2, RX appears to be working while TX is broken.

What I find odd about this is that it means that my original test where I merely added the audio cue had the audio board on UART2--and it worked just fine. The audio board UART is allocated with:

#ifdef ESP32
  #ifndef AUDIO_RX_PIN
    #define AUDIO_RX_PIN 15
  #endif
  #ifndef AUDIO_TX_PIN
    #define AUDIO_TX_PIN 16
  #endif
  // Create a HardwareSerial instance for AudioSerial set to UART2.
  HardwareSerial AudioSerial(2);
#else
  // On Mega 2560, alias AudioSerial to Serial3 instead.
  #define AudioSerial Serial3
#endif

Then it is initialized with AudioSerial.begin(57600, SERIAL_8N1, AUDIO_RX_PIN, AUDIO_TX_PIN);. The audio board then performs a bidirectional handshake to confirm both its presence and its firmware version before the audio functions of our device are allowed to run. Realizing this I then shuffled the UARTs around again so that the audio board would be on UART1 and upstream would be on UART0. Sure enough, the audio board works perfectly fine on UART1 as well.

This means the audio board, which requires bidirectional UART comms to function, works properly on UART0, UART1, and UART2. Yet the upstream comms only work properly on UART0.

By my reading, this suggests that the specific GPIO pins could be playing a part. For some reason pins 15 and 16 work perfectly fine as RX and TX on any UART peripheral, but pins 44 and 43 do not.