Skip to content
On this page

USB board not detected — the ordered checklist

Question this page answers: “I plugged the board in and nothing shows up — where does the chain break?”

The chain has observable breakpoints. Check them in this order; each step has a yes/no answer you can see.

Step 1 — the power LED

BoardWhat lightsIf dark
ESP32-DevKitC5 V power-on LED (not programmable)a power-chain clue: cable/port/charger — verify by swapping before concluding
ESP32-S3-DevKitC-13.3 V power LEDsame power-chain clue — fix power first; a dark LED is a clue to work through, not a verdict
Pico / Pico 2no power LED existsdo step 2 (the cable) anyway, then step 3 — the drive is your observable

Dark LED on an Espressif board points at the power chain first: try another cable and another USB port before anything else; it is a clue to work through, not a final verdict.

Step 2 — the cable

The official ESP32-S3-DevKitC-1 guide calls this out explicitly: some USB cables are charge-only — no data lines. The board powers up (step 1 passes) and flashing then fails silently. The guide’s hardware-setup note names a data cable (USB 2.0 Standard-A to Micro-B) as required hardware. This is one of the most common causes; swap to a known data cable before blaming drivers.

Step 3 — what kind of “detection” you are expecting

The boards expose themselves differently, and “not detected” means different things:

  • Espressif boards (both) — the on-board USB-to-UART bridge (up to 3 Mbps) is what the computer sees. Expected result: a serial device appears. No serial device → bridge driver missing (OS-specific; the ESP-IDF Get Started establish-connection section is the official driver path) or the cable from step 2.
  • ESP32-S3-DevKitC-1 second port — the native USB OTG port is a different chain: it needs the chip firmware/ROM to enumerate, not a bridge. A dead native port together with a working bridge port — on the same proven data cable — narrows the problem toward the chip state; until the cable is proven, the cable is not excluded.
  • Pico / Pico 2 — there is no bridge. This guide uses the BOOTSEL entry: hold BOOTSEL while plugging in, and the board enumerates as a mass-storage drive (RPI-RP2 / RP2350). No drive → repeat the entry with a known data cable and a different port; if it still does not appear, continue with the cable, the port and the OS notes below — those are the first suspects, not the only possible causes. Before any firmware is installed, this drive is what a stock Pico is expected to show.

Step 4 — the mode (flashing “failed to connect”)

If the serial device is there but flashing fails with “Failed to connect”: a typical cause is the chip not entering download mode and auto-sync failing. Manual path per the official guides: hold BOOT, tap EN/Reset, release BOOT (Espressif). On the Pico the flashing path is the BOOTSEL drive from step 3, so this serial-mode step does not apply.

Step 5 — operating-system notes

  • Windows: bridge devices typically need their driver installed once; follow the ESP-IDF establish-connection page for the official path.
  • macOS/Linux: bridge chips usually enumerate without extra drivers; if a serial tool still cannot open the port on Linux, permission setup is covered by the same ESP-IDF page.
  • OS-specific instructions live in the ESP-IDF guide, which is versioned — this page links there instead of copying details that drift.

What this page cannot tell you

  • We did not reproduce these failures on hardware here — the checklist orders official facts (component lists, cable note, BOOTSEL behavior, download-mode buttons) into a diagnostic sequence; the sequence itself is MCUID’s editorial work, not a vendor procedure.
  • Bridge chip part numbers per revision — the pinned guides describe “a USB-to-UART bridge chip” without naming it; we do not guess the part.

Sources