ESP32-C3

Embedding

The CPU and SoC are written from scratch for this site (public domain / CC0) — nothing here wraps a third-party core. rv32-esp32c3.js is a plain RV32IMC interpreter plus an ESP32-C3 SoC model at the real hardware addresses (from the ESP32-C3 TRM and the esp-idf soc.h / reg_base.h). It is all inspectable JavaScript state, which is exactly what lets the shared debugger drive it.

var sys = window.ESP32C3.createSystem();       // RV32IMC core + ESP32-C3 SoC
sys.loadImage(bytes, 0x4037C000);          // flat app image into IRAM
sys.setEntry(0x4037C000);                  // enter at the image start
sys.onUartTx = function(b){ /* UART0 TX -> console */ };
sys.feedRx(byte);                            // keyboard -> UART0 RX FIFO
sys.step();                                  // execute exactly one instruction

We own the run loop so the debugger can drive it. Each frame runs a time-boxed budget of sys.step() (one RV32IMC instruction each); breakpoints stop it by PC, write-watchpoints by bus address. Everything is plain JavaScript state:

Debugger integration

The plug-in (esp32c3-debug.js) describes the ESP32-C3 to the shared debugger and nothing more — the core is not patched:

• Reused decoder. The core runs RISC-V, so the existing /debugger/src/cpus/riscv.js disassembler (RV32I + M + the C compressed forms) is reused as-is under the display name "RISC-V RV32IMC (ESP32-C3)". No new decoder was written.
• Registers are read live each refresh: x0-x31 with their ABI names, the pc, and the machine CSRs (mstatus, mtvec, mepc, mcause, mie, mip, mscratch, mtval, misa). Each has a set() that writes straight back into sys.regs / sys.csrObj.
• Memory is exposed as four chips, all read side-effect-free directly off the typed arrays, each with its real base so the disassembly lines up with PC: IRAM at 0x4037C000 (disassembled), DRAM at 0x3FC80000, XIP flash at 0x42000000 (disassembled), and RTC memory at 0x50000000. The peripheral window is deliberately not a chip, because reading the UART FIFO pops a byte — memory reads stay side-effect-free.
• Single step is one sys.step(). Breakpoints are host-side checks of the PC (in the running code chip's offset space, so a click in the disasm gutter halts) run instruction-by-instruction when any are set. Write-watchpoints are a set the SoC's write path checks, pausing the loop the moment a watched bus address is written.

Architecture

The Espressif ESP32-C3 (2020) is a low-cost WiFi + Bluetooth LE microcontroller built on a single 32-bit RISC-V core:

• RISC-V RV32IMC — one 32-bit core at up to 160 MHz implementing the I base, the M (multiply/divide) and C (compressed) extensions, with machine-mode CSRs, a trap unit and an interrupt matrix. This emulator implements all three extensions, the CSR/trap machinery and a functional interrupt matrix from scratch.
• Memory — 400 KB on-chip SRAM, reachable from the instruction bus at 0x4037C000 (IRAM) and the data bus at 0x3FC80000 (DRAM); code also executes in place (XIP) from external SPI flash mapped at 0x42000000; a small RTC memory sits at 0x50000000. All are at their real hardware addresses.
• On-board LED — devkits expose a user LED on GPIO8, driven through the GPIO block at 0x60004000. (Some boards fit an addressable WS2812 RGB LED there instead; this model drives the plain on/off GPIO LED — see the honest limits below.)
• Serial — UART0 at 0x60000000 is the console the ROM bootloader and apps log to; its TX FIFO drives the serial panel and its RX FIFO is fed by the keyboard.

The bundled firmware is real RISC-V machine code authored for this site (CC0), assembled to flat ESP32-C3 images and run on the from-scratch interpreter. The default is an interactive mini-REPL that evaluates integer expressions over UART0 — because it is real machine code on the real memory map, every instruction single-steps in the debugger and led on visibly toggles the on-board LED.

Honest limits. This is a deliberate honest partial. The from-scratch core runs real RV32IMC and drives the real GPIO / UART / systimer, but the full ESP-IDF / FreeRTOS + WiFi/BLE stack is out of scope: the WiFi and BLE radios have no RF — their register windows are RAM-backed HLE stubs so probing firmware does not hang, but no packets move. The default content is therefore bare-metal, not the full MicroPython/ESP-IDF image; timing is instruction-approximate, not cycle-exact; the WS2812 RGB LED is not decoded (the plain GPIO LED is); and the bare devkit has no on-board audio, so this emulator is naturally silent.