Skip to content
On this page

Serial output is garbled or missing — which link is broken

Question this page answers: “My serial monitor shows garbage, or shows nothing — is the board broken?”

Almost never. Work out which serial path your board uses first, then check the port selection and the baud agreement. The three boards on this site expose serial in three different ways, and mixing them up is the most common cause.

Step 1 — which serial path does your board have?

BoardSerial path to the computerWhat that means for you
ESP32-DevKitCUSB-to-UART bridge only (one micro-USB port, bridge rates up to 3 Mbps)Firmware output goes out over the chip’s UART pins into the bridge — a physical UART link with a baud agreement
ESP32-S3-DevKitC-1Two ports: bridge (micro-USB) and native USB OTG (USB-C)Which one carries your output depends on the firmware build — see first flash; picking the wrong port in your tool shows nothing
Pico / Pico 2No bridge — the chip’s own USB controller (BOOTSEL drive, USB Serial REPL)The USB connection is a virtual serial port; there is no separate bridge UART on the USB path

Step 2 — garbled text: the baud agreement

A physical UART has no clock wire — both ends must agree on the rate. If the tool and the firmware disagree, you see characters, but they are wrong. This applies to:

  • the bridge port on both Espressif boards (the chip’s UART talks to the bridge at a fixed rate your firmware set);
  • any physical UART pins you wired yourself (the UART/I2C/SPI guide covers what a UART link is).

The fix is not exotic: set the serial tool to the rate your firmware prints at (check your project’s serial init), then reset the board and watch from the first line.

A USB CDC connection — the Pico’s USB Serial REPL, or the S3’s native USB port when the firmware uses USB CDC — is a virtual port: the baud field in most tools exists for compatibility and does not rate-limit the link. Garbled text there is not a baud problem; look at the port selection and the cable instead.

Step 3 — completely silent: the port and the mode

  1. Two ports, one tool. On the ESP32-S3-DevKitC-1, a tool listening on the bridge while the firmware prints over native USB (or the reverse) shows nothing. Identify which port your firmware uses, and select that exact device in the tool.
  2. Silent from the very first line? Boot messages appear immediately after reset. Press EN/Reset (Espressif) or re-plug (Pico) while the monitor is open — you should catch the boot output if the link is sound.
  3. No serial device at all? That is not a baud problem — it is the detection chain: work through USB board not detected first.
  4. Board alive but quiet? Verify with something observable: the Pico’s BOOTSEL drive proves the USB chain regardless of firmware; on Espressif boards the power LED only proves power, not firmware. A quiet serial port with a running board usually means the firmware is not printing on the path you are listening to.

What this page cannot tell you

  • We did not reproduce these failures on hardware here. The page orders official facts (bridge presence and rate, two S3 ports, BOOTSEL drive, USB Serial REPL) into a diagnostic sequence; the sequence is MCUID’s editorial work, not a vendor procedure.
  • A table of framework default baud rates. Defaults belong to each framework and change with versions; your project’s own serial init is the authority. This page will not freeze a per-framework table that drifts.
  • The bridge chip part number — the pinned guides describe “a USB-to-UART bridge chip” without naming it; we do not guess the part.

Sources