Zephyr RTOS on ESP32-C6: What's Supported and What's Still Missing
Most developers pick the ESP32-C6 for its triple-radio combo: Wi-Fi 6, BLE 5, and 802.15.4 on a single RISC-V chip. Then they build everything on ESP-IDF because, well, it works. But the moment you need to port that firmware to an nRF5340 or an STM32WB, you’re staring at a rewrite. Zephyr promises a way out: one RTOS, one build system, many silicon vendors. The catch? Espressif support in Zephyr has been a moving target for years, and the ESP32-C6 is one of the newer additions. Some things work great. Some things will quietly ruin your week.
This article gives you two things: a working build you can run in 15 minutes, and an honest peripheral-by-peripheral breakdown so you can make a go/no-go call before you’re 3 months into a project. Everything here references Zephyr v3.7.x (the latest stable as of mid-2025) and the esp32c6_devkitc board target.
The Feature Matrix You Actually Need
Before you touch a terminal, look at this table. It’ll tell you whether your project is even viable on Zephyr today.
+--------------------+-------------+-------------------------------------------+
| Peripheral/Feature | Status | Notes |
+--------------------+-------------+-------------------------------------------+
| GPIO | Supported | Full pin control, interrupts work |
| UART | Supported | Including USB Serial/JTAG console |
| SPI | Supported | Master mode; DMA support may vary |
| I2C | Supported | |
| Timers | Supported | General-purpose and system timer |
| Watchdog | Supported | |
| Flash (SPI NOR) | Supported | Read/write/erase via flash API |
| BLE (NimBLE) | Partial | Advertising, scanning, basic GATT work; |
| | | advanced profiles and pairing less tested |
| Wi-Fi | Experimental| Station mode in progress; gaps remain |
| 802.15.4 / Thread | Supported | Strong upstream integration, OpenThread |
| Deep Sleep | Partial | Works, but limited wake source options |
| ADC | Partial | Functional; eFuse calibration incomplete |
| PWM (LEDC) | Partial | Basic duty cycle control |
| RMT | Not yet | Critical gap for WS2812/NeoPixel users |
| TWAI (CAN) | Not yet | |
| SDIO | Not yet | |
| USB Serial/JTAG | Supported | Built into the C6, no external adapter |
| Secure Boot | Not yet | Must use ESP-IDF tooling |
| Flash Encryption | Not yet | Must use ESP-IDF tooling |
+--------------------+-------------+-------------------------------------------+A few things jump out. The core peripherals (GPIO, UART, SPI, I2C) are solid. Thread/802.15.4 support is genuinely good, arguably better integrated here than in ESP-IDF for some use cases. But Wi-Fi is still experimental, BLE has rough edges, and security features like secure boot are absent entirely.
If your project depends on anything marked “Not yet,” stop here. Zephyr isn’t the right choice today. If everything you need is “Supported” or “Partial,” keep reading.
Build Walkthrough: Hello World on ESP32-C6
Prerequisites
You need a working Zephyr development environment: Zephyr SDK installed, a west workspace initialized, and a Python virtual environment active. If you don’t have this yet, follow the Zephyr Getting Started guide. Don’t try to shortcut it. The Espressif-specific quick start guide in the Hubble docs for Espressif also covers workspace setup with useful context for BLE-focused projects.
Fetch the Espressif HAL
From your Zephyr workspace root, pull in all modules:
west updateThis fetches hal_espressif, which contains Espressif’s hardware abstraction layer and the binary blobs needed for BLE and Wi-Fi. Confirm it’s there:
ls ../modules/hal/espressifYou should see directories like components, zephyr, and a west.yml. If the module is missing, your west.yml manifest might not include the Espressif remote. Check that you’re on the main Zephyr manifest, not a stripped-down fork.
Build the Sample
Here’s the exact command:
west build -b esp32c6_devkitc/esp32c6 samples/hello_worldThe board target string matters. It’s esp32c6_devkitc/esp32c6, not esp32c6_devkitc alone. Zephyr v3.7.x uses the board/soc format for multi-SoC boards. Get this wrong and you’ll see a cryptic “board not found” error.
A clean build takes 1 to 3 minutes depending on your machine. You’ll see CMake configure the RISC-V toolchain from the Zephyr SDK, pull in the ESP32-C6 device tree, and compile. Expected final output:
[100%] Built target zephyr_final
Memory region Used Size Region Size %age Used
FLASH: 25432 B 2 MB 1.21%
RAM: 9876 B 512 KB 1.88%(Your numbers will differ slightly.)
Flash and Monitor
The ESP32-C6 has a built-in USB Serial/JTAG peripheral. Plug in the USB-C cable and you’re connected. No FTDI adapter, no driver headaches on most systems.
west flashThen open a serial monitor:
west espressif monitorIf west espressif monitor isn’t available in your install, fall back to:
minicom -D /dev/ttyACM0 -b 115200(On macOS, the device is probably /dev/cu.usbmodem*.)
Verify Output
You should see:
*** Booting Zephyr OS build v3.7.0 ***
Hello World! esp32c6_devkitc/esp32c6You have Zephyr running on RISC-V silicon.
Common Build Errors and Fixes
“Board esp32c6_devkitc not found” — You’re using the old board name format. Use esp32c6_devkitc/esp32c6 with the SoC qualifier.
“Missing binary blobs” — Run west blobs fetch hal_espressif. The BLE and Wi-Fi stacks need proprietary blobs that aren’t pulled by default in some configurations.
Python dependency errors during CMake — Your venv is probably stale. Re-run pip install -r zephyr/scripts/requirements.txt from the workspace root.
BLE on ESP32-C6 with Zephyr: The Real Litmus Test
Hello World proves the toolchain works. BLE proves whether Zephyr is viable for your actual product. Let’s build a BLE beacon.
west build -b esp32c6_devkitc/esp32c6 samples/bluetooth/beacon -- \
-DEXTRA_CONF_FILE=boards/esp32c6_devkitc.confIf a board-specific config file doesn’t exist in that sample, create a Kconfig overlay. At minimum, you need:
CONFIG_BT=y
CONFIG_BT_PERIPHERAL=y
CONFIG_BT_DEVICE_NAME="Zephyr-C6"The ESP32-C6 uses NimBLE as the BLE host stack in Zephyr, with Espressif’s BLE controller blob underneath. Flash the build, open a BLE scanner app on your phone (nRF Connect works well), and look for “Zephyr-C6.”
What works: basic advertising, scanning, GATT server and client, simple connection handling. For many IoT use cases, this is sufficient.
What’s shaky: some advanced pairing modes, throughput-intensive data transfer, and niche profiles. HID over GATT, L2CAP CoC, extended advertising with chained PDUs: test each of these explicitly before committing. The NimBLE stack itself supports these features, but the controller blob integration on ESP32-C6 may not exercise all code paths reliably yet.
If BLE is your primary connectivity, consider building against the Zephyr device SDK reference for BLE to understand how advertising packets are structured for production use. This gives you a tighter feedback loop than working from raw Zephyr samples alone.
The Honest Gap Analysis
Wi-Fi Is the Biggest Gap
ESP-IDF’s Wi-Fi stack has been hammered in production for years. WPA3, AP mode, mesh networking, power save modes, roaming: it’s all there and battle-tested. Zephyr’s ESP32-C6 Wi-Fi support is experimental. Station mode is in progress, but AP mode, WPA3, and advanced power save aren’t reliably available. If your product needs Wi-Fi, ESP-IDF is the pragmatic choice today.
Missing Peripherals
RMT (Remote Control Transceiver) is the standard way to drive WS2812 LEDs and IR protocols on ESP32 chips. It’s not in Zephyr for the C6 yet. Neither is TWAI (Espressif’s CAN controller) or SDIO. These aren’t exotic peripherals; they’re common in consumer and industrial products. Check the matrix against your schematic before you start.
Security and Binary Blobs
Secure boot and flash encryption are table stakes for production firmware. Zephyr doesn’t support either on the ESP32-C6 yet. You can’t mix and match here easily: these features are tightly coupled to the bootloader and flash layout. If you need them, you’re on ESP-IDF.
This connects to a broader issue. Even in Zephyr, BLE and Wi-Fi on the ESP32-C6 depend on Espressif’s closed-source binary blobs. If you chose Zephyr partly for its open-source ethos, the RF stacks are still opaque. On the practical side, blob versions must match the HAL version, and mismatches produce silent failures that are genuinely miserable to debug.
Power Management Is Half-Built
Deep sleep works, but the available wake sources are limited compared to ESP-IDF, where you can wake from GPIO, touch, ULP coprocessor, or timer with fine-grained control. If your product runs on a battery and needs microamp sleep currents with flexible wake triggers, budget real time for testing before you commit to Zephyr here.
Community Size
ESP-IDF has a decade of StackOverflow answers, forum posts, and example projects. Zephyr’s Espressif community is growing, but it’s still maybe a tenth the size. When you hit a weird DMA bug at 2 AM, that difference matters.
Choosing Your Framework: A Decision Checklist
Choose Zephyr if:
✓ You need multi-vendor hardware portability (nRF + ESP32 + STM32)
✓ Thread/Matter is your primary connectivity
✓ Your organization is standardizing on Zephyr across teams
✓ You want upstream RTOS primitives, not FreeRTOS
✓ Your peripheral needs are covered by the "Supported" rows above
Stay on ESP-IDF if:
✓ You need mature Wi-Fi (WPA3, AP mode, mesh, power save)
✓ You depend on RMT, TWAI, or other unlisted peripherals
✓ You need secure boot or flash encryption for production
✓ Battery life is critical and you need deep sleep flexibility
✓ Your team already ships ESP-IDF products and has the muscle memoryMany teams land in a gray zone: they need portability but also need Wi-Fi. For those cases, prototype your critical path on Zephyr first. Build the most demanding feature (not Hello World), run it for a week, and see what breaks. That costs you a few days. Discovering the gaps 3 months in costs you a quarter.
Build Your Hardest Feature First
Zephyr on the ESP32-C6 has crossed the threshold from “interesting experiment” to “viable for the right project.” The build system works, core peripherals are solid, and Thread/802.15.4 support is genuinely strong. If you’re building a Matter device or a Thread border router, Zephyr is arguably the better choice today.
But the gaps are real. Wi-Fi, security, power management, and several peripherals are still catching up. Espressif’s upstream contributions are accelerating, but you’re shipping firmware today.
Flash your most demanding sample. Test the specific peripherals on your BOM. That’s the only way to turn this article’s table into a real decision for your project. If you’re integrating BLE devices into a broader cloud pipeline, the Zephyr quick-start guide for Hubble walks through an end-to-end path worth evaluating alongside vanilla Zephyr samples.
Hubble Network enables direct satellite connectivity for BLE devices—no gateways, no terrestrial infrastructure required. See how it works →