ESP32-S3 UART Example: Wiring, Code, and Bus Debugging

Physical Layer: Wiring the ESP32-S3 UART Bus

Unlike synchronous buses that rely on a shared clock line, Universal Asynchronous Receiver-Transmitter (UART) communication is entirely dependent on agreed-upon timing and strict physical layer rules. The ESP32-S3 features three hardware UART controllers (UART0, UART1, and UART2). Because UART0 is typically routed to the onboard USB-CDC or CP2102 chip for serial flashing and console output, you will almost always use UART1 or UART2 for external device communication.

The ESP32-S3 utilizes a flexible GPIO matrix, meaning you can map the UART TX and RX signals to nearly any available pin. However, you must avoid strapping pins (like GPIO0, GPIO3, GPIO45, and GPIO46) which dictate boot modes on reset. For a reliable physical connection, cross your data lines: the ESP32-S3 TX pin must connect to the target device's RX pin, and vice versa.

Regarding pull-up resistors: standard TTL UART lines idle HIGH and do not require external pull-up resistors for basic point-to-point communication. The internal weak pull-ups are sufficient to prevent floating inputs when a cable is disconnected, but for runs longer than 30cm, rely on the driven signal rather than adding external resistors which can soften the rising edge and cause framing errors at high baud rates.

Bus Mechanics: UART vs I2C vs SPI

Choosing the right protocol depends entirely on your constraints regarding distance, speed, and device count. UART is a point-to-point asynchronous protocol, making it ideal for debugging, GPS modules, and cellular modems, but poorly suited for multi-device sensor networks.

If you need to connect 15 temperature sensors on the same bus, I2C wins due to its addressing scheme. If you need to push raw pixel data to an LCD, SPI is mandatory for the bandwidth. But if you are talking to a single external microcontroller or a SIM7600 LTE modem, UART is the simplest, most robust choice.

Minimal Working ESP32-S3 UART Example

Below is a complete, copy-pasteable Arduino framework example. This code initializes UART1 on GPIO 17 (TX) and GPIO 18 (RX), sends a handshake ping, and listens for a response with a non-blocking timeout.

Hardware Wiring for this Example:

• ESP32-S3 GPIO 17 (TX) → Target Device RX
• ESP32-S3 GPIO 18 (RX) → Target Device TX
• ESP32-S3 GND → Target Device GND (Mandatory common ground)

#include <HardwareSerial.h>

// Initialize UART1
HardwareSerial MySerial(1);

const int RX_PIN = 18;
const int TX_PIN = 17;
const long BAUD_RATE = 115200;

void setup() {
  // Initialize native USB serial for debugging
  Serial.begin(115200);
  while (!Serial) { delay(10); }
  
  // Initialize UART1 with specific GPIO mapping
  // Parameters: baud, config, rx_pin, tx_pin
  MySerial.begin(BAUD_RATE, SERIAL_8N1, RX_PIN, TX_PIN);
  
  Serial.println("ESP32-S3 UART1 initialized on GPIO 17/18");
  
  // Send initial handshake
  MySerial.println("PING");
}

void loop() {
  // Non-blocking read with timeout
  if (MySerial.available() > 0) {
    String incoming = MySerial.readStringUntil('\n');
    incoming.trim();
    
    if (incoming == "PONG") {
      Serial.println("Handshake successful. Device is alive.");
      // Send a data payload
      MySerial.print("DATA:");
      MySerial.println(millis());
    } else {
      Serial.print("Unexpected payload: ");
      Serial.println(incoming);
    }
  }
  
  // Keep the loop responsive
  delay(100);
}

For deeper hardware configuration, such as adjusting the FIFO thresholds or enabling hardware flow control (RTS/CTS), consult the official Espressif ESP32-S3 UART API documentation.

Sniffing and Debugging the Bus

Every protocol has its classic failure mode. I2C silently hangs from a missing pull-up resistor on SDA/SCL. Multi-drop RS-485 networks crash from an address clash or termination reflection. But for point-to-point TTL UART, the classic failure is a baud mismatch or a floating ground reference.

If your ESP32-S3 is receiving garbage characters (like `0xFF`, `??`, or random ASCII symbols), the physical layer is likely intact, but the timing is wrong. A 115200 baud transmitter talking to a 9600 baud receiver will result in framing errors because the receiver samples the start bit and subsequent data bits at the wrong intervals.

How to sniff and debug the bus:

1. Use a Logic Analyzer: A $15 USB logic analyzer (like a Saleae clone) running PulseView or Sigrok is invaluable. Connect the probe to the TX line, set the trigger to the falling edge of the start bit, and sample at least 4x your baud rate (e.g., 1 MHz sample rate for 115200 baud).
2. Measure the Bit Width: Use the analyzer's cursors to measure the width of a single bit. At 115200 baud, one bit should be exactly 8.68 µs. If it measures 104 µs, your device is actually transmitting at 9600 baud.
3. Check the Ground: If the signal looks clean on the oscilloscope but the ESP32-S3 still drops bytes, check the voltage difference between the two boards' GND pins. A ground loop or missing ground wire will cause the receiver's threshold comparator to misread logic HIGHs and LOWs.

Frequently Asked Questions

Can I use any GPIO pin for my ESP32-S3 UART example?

Technically, the ESP32-S3 GPIO matrix allows you to route UART signals to almost any pin, but practically, you must avoid strapping pins and pins tied to internal flash/PSRAM. Never use GPIO26 through GPIO32, as these are strictly reserved for internal SPI flash and octal SPI PSRAM communication on most DevKitC modules. Additionally, avoid GPIO0, GPIO3, GPIO45, and GPIO46, as these dictate the boot mode (download vs. normal execution) during the reset sequence. Stick to safe general-purpose pins like GPIO 17, 18, 38, or 39.

Why is my ESP32-S3 receiving garbage data over UART?

Garbage data almost always points to one of three issues: a baud rate mismatch, an incorrect data framing configuration (e.g., the sender is using 8-E-1 parity while the ESP32-S3 is configured for 8-N-1), or a missing common ground. If you are using long wires (over 50cm), capacitance and crosstalk can round off the sharp square edges of the TTL signal, causing the receiver's UART peripheral to misinterpret the bit boundaries. Twisting your TX/RX wires with the GND wire or dropping the baud rate to 9600 will usually resolve long-run signal integrity issues.

How do I connect a 5V Arduino to the 3.3V ESP32-S3 UART?

You must shift the voltage levels to prevent destroying the ESP32-S3's RX pin. The cleanest method is using a dedicated MOSFET-based bidirectional logic level shifter module (like the Texas Instruments TXB0104 or a generic BSS138 breakout board). If you are in a pinch and only need to shift the 5V Arduino TX down to the 3.3V ESP32-S3 RX (since the ESP32-S3's 3.3V TX is usually recognized as a valid HIGH by a 5V Arduino RX), you can build a quick voltage divider using a 1kΩ resistor in series with the 5V TX line, and a 2kΩ resistor pulling the ESP32-S3 RX side to ground. This drops the 5V signal down to a safe ~3.3V.