ESP-IDF 6.0: what changed, and whether to upgrade from 5.5

tedder — Sun, 12 Jul 2026 21:41:00 GMT

After running a uniform fleet of ESP32 devices on ESP-IDF v5.5.4 for months, I evaluated the jump to v6.0.2. The short answer: no urgency for existing projects, but the upgrade is clean and v6 is worth choosing for new work.

What got better in v6

Picolibc replaces Newlib — This is the headline win. Picolibc is smaller (flash), faster, and uses less RAM. Free win on all chips, especially memory-constrained S2 and original ESP32. See the Picolibc vs Newlib comparison.

New chips and matured C6 support — C5, C61 (preview), and full ESP32-C6 support. The C6 in particular is where v6 shines: Wi-Fi 6 (802.11ax) with TWT (Target Wake Time) for connected low-power operation, native 802.15.4 (Thread/Zigbee/Matter), and a genuine low-power core (not a tiny ULP helper like S2/S3 have).

Recovery bootloader (C5/C61 only) — Safe OTA of the bootloader itself, not just the app. If the bootloader write fails or loses power mid-flash, the chip boots a recovery copy from a dedicated partition instead of bricking. See ESP-IDF bootloader OTA docs.

Wi-Fi driver robustness — WPA3 mixed-mode AP (SoftAP serves WPA3 but still accepts WPA2-PSK clients), USD (peer discovery), general reconnect/roaming improvements.

Tooling — Installation Manager (EIM) for managing versions side-by-side, MCP server support, idf.py CLI extensions.

Active development — v5.5.x is trending maintenance-only. v6 is where new features land.

What breaks (or requires attention)

Warnings are now errors by default. This is the most likely migration friction. Each of your 13 projects may need warning cleanup on the first v6 build—either fix them or re-disable the flag. See the official migration guide.

Toolchain bumps — CMake 3.22.1 minimum, esp-idf-kconfig v3 (Kconfig syntax changes, only matters if you have custom Kconfig).

idf.py requires -p flag for eFuse commands. If you have automation that does idf.py burn_efuse or similar without specifying the port, it breaks.

Legacy drivers removed — ADC, DAC, I2S, Timer, PCNT, MCPWM, RMT, temp-sensor drivers are gone. I scanned my fleet; none use them (though RMT's esp_led_strip component is NOT removed, and driver/ledc.h for PWM is fine). Check your projects for raw driver/adc.h, driver/dac.h, etc.

Picolibc differences — The libc swap can surface subtle printf, locale, float-formatting, or stdio differences. Low-risk, but test rather than assume.

Effort — Multiplied by the number of projects. Re-running idf.py set-target, rebuilding, re-OTA'ing 13 devices takes time. Not a blocker, just real.

My migration strategy

Staged trial: install v6.0.2 side-by-side with v5.5.4. Start with one low-stakes project (e.g., a development board or a device you can easily recover), clear warnings-as-errors fallout, confirm OTA works, then roll the rest opportunistically.

Keep v5.5.4 until all projects are confirmed running on v6.0.2. That gives a fallback if something unexpected surfaces.

For new projects, start directly on v6.0.2. No point dragging v5.5.4 into new work.

Bootloader OTA: the chip-specific caveat

If you're planning safe OTA of the bootloader itself (not just the app), watch chip support:

C5 / C61: Full recovery bootloader with eFuse fallback. Safe. Use it.
C6, S2, S3: No recovery bootloader. Only app OTA is safe. Bootloader must be flashed once over USB and left alone—OTA-ing the bootloader on these chips is risky (no fallback if the write fails).

C6 practical rule: App OTA + rollback = safe/supported. Bootloader OTA = still risky. If bullet-proof bootloader OTA is a hard requirement, prefer C5 or C61, not C6.

C6 vs S2 vs S3 at a glance

For battery devices that need to stay Wi-Fi-connected on battery, the C6 is a different animal from S2/S3.

ESP32-S2

Cores: 1× Xtensa LX7 @ 240 MHz
Low-power: ULP-RISC-V (tiny helper, limited fixed functions)
WiFi: Wi-Fi 4 (802.11n)
BLE: None
Connected power: ~mA (frequent DTIM wakeups)

ESP32-S3

Cores: 2× Xtensa LX7 @ 240 MHz
Low-power: ULP-RISC-V (same as S2)
WiFi: Wi-Fi 4 (802.11n)
BLE: BLE 5
Connected power: ~mA (frequent DTIM wakeups)

ESP32-C6

Cores: 1× RISC-V HP @ 160 MHz
Low-power: Real LP core (full RISC-V with LP UART/I2C/ADC/GPIO)
WiFi: Wi-Fi 6 (802.11ax)
BLE: BLE 5
802.15.4: Yes (Thread/Zigbee/Matter)
Connected power: ~µA with TWT

Key differences:

TWT (Target Wake Time) is a Wi-Fi 6 feature (C6-only). The chip negotiates sleep windows with the AP while staying associated — can cut average current ~10× vs S2/S3 which need frequent DTIM wakeups.

LP core means real sensor/comms loops can run on the low-power core while the HP core sleeps — not a "tiny helper" like S2/S3 ULP, but an actual programmable MCU with peripherals.

What I'm doing

Existing fleet (13 projects on v5.5.4): Staying put unless a specific reason to upgrade surfaces (bug fix, new feature, hardware issue). Low urgency.

New work: C6 on v6.0.2 from the start, taking advantage of TWT, LP core, and the full v6 tooling.

Test upgrade (Q3 2026): Pick one S3 project (attic-temperature-sensor or rain-sensor), do the staged trial, confirm OTA, then roll out to the rest if no surprises.

The migration is not risky — it's just not urgent for devices already working on v5.5.4.

blog.tedder.dev (Posts about c)