Espressif already published the QEMU ESP32 limitations list

People keep asking whether QEMU can run their ESP32 firmware. Espressif already answered. The answer is a table in a README, and the peripherals people buy the chip for are marked with a red X.

I wrote about what QEMU covers on Cortex-M. This is the other popular QEMU story in embedded, and it is cleaner, because the vendor drew the map themselves.

The table nobody scrolls to

ESP-IDF's QEMU page is a how-to. Install the fork. idf.py qemu monitor. Debug with GDB. Emulate eFuses so you can test secure boot without burning a part. It does not list what is missing.¹

The missing list lives one click further, in Espressif's toolchain-docs README. Supported features, three columns, ESP32 / ESP32-S3 / ESP32-C3.²

The green side is real work. Dual-core. UART. Interrupt matrix. NOR flash and its MMU. PSRAM. eFuse. RNG. AES, SHA, RSA. Timer groups. TWAI. On ESP32, SD/MMC and LEDC.

Then the red side, identical across all three chips:

Feature	ESP32	ESP32-S3	ESP32-C3
Wi-Fi	no	no	no
Bluetooth	no	no	no
USB	no	no	no
RMT	no	no	no
GP SPI	no	no	no
I2C	no	no	no
I2S	no	no	no
ULP (co-processor)	no	no	no
GPIO matrix / IOMUX	no	no	no

Wi-Fi has a note: "The Ethernet controller can be used for networking instead." That controller is also starred. It is OpenCores Ethernet. It is not a real ESP32 peripheral. The RGB framebuffer is the same kind of star: a host convenience, not silicon.²

What that list actually means

An ESP32 without Wi-Fi, Bluetooth, USB, RMT, SPI, I2C, I2S, the ULP, and the GPIO matrix is not "an ESP32 with a few gaps." Those are the reasons people buy the part.

QEMU will still boot a lot of firmware. The CPU is there. Flash is there. UART is there. Crypto is there. If your test is "does this image start, print, and sit in a loop," the fork is a legitimate target. Espressif even ships prebuilt binaries and wires them into idf.py.¹

The moment the firmware talks to the radio, a sensor bus, a WS2812 chain, a USB gadget, or the ULP, you have left the model. The README is not coy about this. The support paragraph under the table says Espressif does not provide support for QEMU, and that they will "likely not be able to help with particular use cases which aren't supported yet (e.g. due to missing emulation of some peripherals)."²

That is a vendor telling you the unsupported set is expected, not a temporary omission they forgot to mention.

When someone opens an issue because esp_wifi_init crashes in QEMU, the reply is the same table. Wi-Fi is not supported. Use the OpenCores Ethernet path if you need a network. File QEMU bugs in the QEMU repo, not in ESP-IDF.³

The stand-ins are a tell

Two green ticks in that table are not hardware. OpenCores Ethernet exists so you can have a socket. The RGB framebuffer exists so you can look at pixels. Both notes say so in plain language.²

That is a coherent engineering choice. Networking tests and GUI tests are useful. Faking the ESP32 MAC and PHY well enough to run esp_wifi is a different project, and Espressif did not take it on. The Ethernet stand-in is the honest substitute: you get packets, you do not get a radio.

A December 2025 walkthrough of "internet in QEMU" has to spend most of its length on exactly this reroute — enable OpenEth, init a MAC that is not on the chip, turn off hardware crypto because that path misbehaves, accept that Wi-Fi is gone.⁴ The workarounds are the product. They are not a path back to the missing peripherals.

What this is good for, and what it is not

Same as Ozone-Sim. Scope first, then the question you are allowed to ask.

Question	Espressif QEMU
Does this image boot and print on UART?	Yes, that is the happy path
Can I step it in GDB without a probe?	Yes, idf.py qemu gdb
Can I burn fake eFuses and test secure boot?	Yes, that is a documented feature
Does my HTTPS client get a socket?	Yes, through OpenCores Ethernet, not Wi-Fi
Does esp_wifi_init work?	No
Does my I2C sensor come up?	No — I2C is unsupported on every chip
Does my RMT LED strip bit-bang correctly?	No
Does the ULP wake the main cores the way silicon does?	No

Modeling Wi-Fi and the GPIO matrix to silicon fidelity is expensive, and most of what this fork is worth is "run the binary without flashing." That is real. It is also not the same as "this is the chip."

I have written about what simulation can't catch — the cases where the simulator answers anyway. Espressif's table is the better failure mode. The unsupported set is written down. The crash when you init Wi-Fi is a loud no, not a quiet zero. The README does not claim timing fidelity either; this fork is not in the cycle-accurate conversation.

The green ticks are what still bites people. LEDC is yes on ESP32 and no on S3 and C3. SD/MMC is yes on ESP32 and no on S3. "QEMU supports ESP32" is not a sentence that transfers across the family.

Treat Espressif QEMU as a host for the parts of the image that do not touch the red rows. That is a useful CI target. It is not a substitute for the radio, the buses, or the ULP, and the people who built it already said so.

Sources

Footnotes

1. Espressif, "QEMU Emulator," ESP-IDF Programming Guide v6.0.2, accessed 2026-08-14. https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-guides/tools/qemu.html ↩ ↩²

2. Espressif, "QEMU README," esp-toolchain-docs, accessed 2026-08-14. https://github.com/espressif/esp-toolchain-docs/blob/main/qemu/README.md ↩ ↩² ↩³ ↩⁴

3. Espressif, "Initializing WiFi in QEMU crashes the application," esp-idf issue 15087, 2024-12-24. https://github.com/espressif/esp-idf/issues/15087 ↩

4. Production ESP32, "ESP32 Internet Access in QEMU," 2025-12-19. https://productionesp32.com/posts/internet-in-qemu/ ↩