ESP32-C3

The ESP32-C3 is Espressif Systems’ first RISC-V SoC, introduced in 2020 as the low-cost RISC-V replacement for the ESP8266 in the Espressif lineup. It pairs a single-hart 32-bit RISC-V core (“ESP-RISC-V CPU”), a 4-stage in-order scalar pipeline clocked at up to 160 MHz, 400 KB of internal SRAM, 384 KB of internal ROM, a 16 KB read-only cache for external flash, 2.4 GHz Wi-Fi (802.11 b/g/n), Bluetooth 5 Low Energy, and the usual smorgasbord of MCU peripherals (two UARTs, three SPIs, I²C, I²S, USB Serial/JTAG, TWAI/CAN, ADC, RNG, AES, SHA, RSA, HMAC, digital signature) in a 5 mm × 5 mm QFN-32 package (Espressif, ESP32-C3 Technical Reference Manual v1.4; Espressif, ESP32-C3 Series Datasheet v2.4). The core implements RV32IMC with Zicsr/Zifencei, supports only Machine and User privilege modes, has 16 PMP regions, a vectored-only mtvec, and an Espressif-designed interrupt controller with 31 vectored interrupts at 15 priority levels (TRM §1.2, §1.5, §1.8). It runs FreeRTOS under ESP-IDF as its supported software stack, with NuttX, Zephyr, and Rust’s esp-hal as community alternatives. Per the datasheet’s CoreMark line the C3 achieves 483.27 CoreMark at 160 MHz, or 3.02 CoreMark/MHz, on par with other small in-order RV32IMC cores. The definitely-not-esp32 project benchmarks its from-scratch SoC against an ESP32-C3, which is why this note exists.

Chip vs Dev Board

Two distinct things share the “ESP32-C3” name and the same product page, and the distinction routinely confuses newcomers:

• The chip (ESP32-C3 SoC) is the bare 5×5 mm QFN-32 die. It needs a host PCB, antenna, crystal, supply regulation, and either external flash or a flash-equipped package variant (ESP32-C3FN4 with 4 MB in-package flash, ESP32-C3FH4X with 4 MB, ESP32-C3FH8X with 8 MB; see Datasheet v2.4 page 1).
• The dev boards that put the chip on a hobbyist-friendly board with USB, regulator, antenna, and pin headers. Espressif sells two reference designs:
  • ESP32-C3-DevKitM-1. based on the small ESP32-C3-MINI-1 or MINI-1U module with the bare-chip antenna trace. Compact form factor, “named for its small size” (Espressif DevKitM-1 user guide).
  • ESP32-C3-DevKitC-02. based on the larger ESP32-C3-WROOM-02 module, 4 MB SPI flash, 22 GPIO pins exposed on dual headers, Micro-USB connector with USB-to-UART bridge “providing transfer rates up to 3 Mbps” (Espressif DevKitC-02 user guide; esp-dev-kits docs). The DevKitC-02 is the larger-form-factor breadboard-friendly variant.

When this note says “ESP32-C3” it means the silicon. When it refers to the dev board, it says “DevKitM-1” or “DevKitC-02.”

Mental Model

A single RISC-V core sits at the top of a small split-bus topology: an instruction bus (IBUS) and a data bus (DBUS) feed it directly from the on-chip SRAM and ROM, and an AHB system bus fans out to every peripheral. A debug module hangs off the same complex with JTAG access, and an interrupt controller multiplexes 31 peripheral interrupt lines into the core’s trap entry. The radios (Wi-Fi MAC + baseband, Bluetooth LE link controller + baseband) sit as memory-mapped peripherals on the system bus, with dedicated DMA channels (GDMA) for high-throughput peripherals. Security blocks (AES, SHA, RSA, HMAC, RNG, digital signature) are first-class peripherals, not driver-only software.

flowchart TB
  subgraph CPU["ESP-RISC-V CPU (RV32IMC, 4-stage, 160 MHz max)"]
    CORE["RV32IMC core<br/>(M+U privilege, 16 PMP regions,<br/>vectored-only mtvec)"]
    INTC["INTC<br/>31 vectored IRQs,<br/>15 priority levels"]
    DM["Debug Module<br/>(RISC-V dbg v0.13.2,<br/>8 hw breakpoints)"]
    SYSBUS{"SYS BUS"}
    CORE -- "IBUS" --> SYSBUS
    CORE -- "DBUS" --> SYSBUS
    INTC --> CORE
    DM <--> CORE
  end
  subgraph MEM["On-chip memory (792 KB I-bus / 552 KB D-bus space)"]
    IRAM["IRAM/DRAM:<br/>400 KB SRAM<br/>(16 KB used as cache)"]
    ROM["384 KB Internal ROM<br/>(mask ROM)"]
    RTCM["8 KB RTC FAST<br/>(deep-sleep persistent)"]
    CACHE["Uniform read-only cache<br/>16 KB · 8-way · 32 B line<br/>(for external flash via MMU)"]
  end
  subgraph PER["Peripherals (AHB, 836 KB peripheral space)"]
    GDMA["GDMA: 3 Tx + 3 Rx ch.<br/>(SPI2 / UHCI / I2S / AES / SHA / ADC)"]
    UART["2 × UART"]
    SPI["3 × SPI"]
    I2C["I2C"]
    I2S["I2S"]
    USB["USB Serial/JTAG"]
    TWAI["TWAI (CAN 2.0)"]
    LEDC["LED PWM"]
    RMT["Remote control"]
    ADC["2 × 12-bit SAR ADC"]
    TMR["Timer Group<br/>+ 52-bit system timer"]
    WDT["3 × digital + analog WDT"]
    GPIO["GPIO matrix"]
  end
  subgraph SEC["Security & RTC"]
    SBOOT["Secure Boot V2<br/>(RSA-3072)"]
    FENC["Flash Encryption<br/>(AES-128/256 XTS)"]
    AES["AES"]
    SHA["SHA"]
    RSA["RSA"]
    HMAC["HMAC"]
    DS["Digital Signature"]
    RNG["RNG"]
    EFUSE["4096-bit eFuse<br/>(1792 user bits)"]
    RTCM2["RTC Memory + PMU"]
  end
  subgraph RF["RF and Wireless"]
    WIFI_MAC["Wi-Fi MAC + Baseband<br/>(802.11 b/g/n, 2.4 GHz)"]
    BLE_LL["BLE Link Controller +<br/>Baseband (BT 5 LE, mesh)"]
    BALUN["RF balun + PA + LNA<br/>(shared 2.4 GHz path)"]
  end
  EXTF["External QSPI/QPI flash<br/>up to 16 MB (off-package or<br/>in-package up to 8 MB)"]
  SYSBUS <--> IRAM
  SYSBUS <--> ROM
  SYSBUS <--> RTCM
  SYSBUS <--> CACHE
  CACHE <-->|"MMU"| EXTF
  SYSBUS <--> GDMA
  GDMA <--> UART
  GDMA <--> SPI
  GDMA <--> I2S
  GDMA <--> AES
  GDMA <--> SHA
  GDMA <--> ADC
  SYSBUS <--> I2C
  SYSBUS <--> USB
  SYSBUS <--> TWAI
  SYSBUS <--> LEDC
  SYSBUS <--> RMT
  SYSBUS <--> TMR
  SYSBUS <--> WDT
  SYSBUS <--> GPIO
  SYSBUS <--> SBOOT
  SYSBUS <--> FENC
  SYSBUS <--> RSA
  SYSBUS <--> HMAC
  SYSBUS <--> DS
  SYSBUS <--> RNG
  SYSBUS <--> EFUSE
  SYSBUS <--> RTCM2
  SYSBUS <--> WIFI_MAC
  SYSBUS <--> BLE_LL
  WIFI_MAC <--> BALUN
  BLE_LL <--> BALUN
  GPIO --> INTC
  UART --> INTC
  SPI --> INTC
  WIFI_MAC --> INTC
  BLE_LL --> INTC

Block diagram of the ESP32-C3 SoC, redrawn from the TRM Figure 1.1-1 (CPU Block Diagram) and the Datasheet v2.4 Functional Block Diagram. What it shows: the RV32IMC core, its INTC and debug module sit as one complex feeding a system bus. The bus reaches three classes of slave: on-chip memories (400 KB SRAM + 384 KB ROM + 8 KB RTC + the 16 KB cache that fronts external flash via the MMU), peripherals (UART/SPI/I²C/I²S/USB/TWAI/LEDC/RMT/ADC/timers/WDT/GPIO), and security and wireless blocks. Wi-Fi and BLE share a single 2.4 GHz analog path with hardware coexistence. The insight to take: this is a fairly minimal SoC organisation, and almost every block has a public register-level description in the TRM. That is what makes it a good benchmarking target for a from-scratch RISC-V SoC: the comparison is fair when both sides have the same primitives.

The CPU: ESP-RISC-V

Espressif designates the core “ESP-RISC-V CPU” in the TRM and does not name an upstream IP vendor. The TRM opens chapter 1 with: “ESP-RISC-V CPU is a 32-bit core based upon RISC-V ISA comprising base integer (I), multiplication/division (M) and compressed (C) standard extensions. The core has 4-stage, in-order, scalar pipeline optimized for area, power and performance” (TRM §1.1). The machine-information CSRs are hardwired to mvendorid = 0x00000612, marchid = 0x80000001, mimpid = 0x00000001, mhartid = 0x00000000 (TRM v1.4 §1.4.2 Registers 1.1-1.4), and each of those values carries meaning under the privileged specification.

mvendorid is not a free-form number: it “provid[es] the JEDEC manufacturer ID of the provider of the core”, encoded as a Bank field holding the count of 0x7f continuation bytes and an Offset field holding the final byte with its parity bit stripped (riscv-isa-manual, src/priv/machine.adoc, main branch). Decoding 0x612: Bank = 0x612 >> 7 = 12 (twelve continuation codes, i.e. JEDEC bank 13, since the spec notes “the bank number is one greater than the number of continuation codes”), Offset = 0x612 & 0x7f = 0x12. That is Espressif’s own JEDEC assignment. SiFive’s registered vendor ID is 0x489 (Linux arch/riscv/include/asm/vendorid_list.h) and the C3 does not report it.

marchid = 0x80000001 is equally telling. The spec splits the architecture-ID space by most-significant bit: “Open-source project architecture IDs are allocated globally by RISC-V International, and have non-zero architecture IDs with a zero most-significant-bit (MSB). Commercial architecture IDs are allocated by each commercial vendor independently, but must have the MSB set.” It adds that “commercial fabrications of open-source designs should (and might be required by the license to) retain the original architecture ID.” With the MSB set and the remaining bits equal to 1, Espressif is declaring this the first closed-source microarchitecture in its own vendor namespace — not a re-badge of anyone else’s registered design.

The SiFive E2 rumour, traced to its source

A persistent secondary-source claim holds that the ESP-RISC-V core is a licensed SiFive E2-series design. Tracing it back settles the matter.

Resolved 2026-08-08

The SiFive E2 attribution is unsourced. A full-text search of TRM v1.4 (dated 2026-03-26 in its Revision History) returns zero occurrences of the string “SiFive”, and so does Datasheet v2.4. Espressif names the core only “ESP-RISC-V CPU” (§1.1) and stamps it with its own vendor, architecture, and implementation IDs (§1.4.2), where marchid’s set MSB explicitly marks a vendor-allocated commercial microarchitecture rather than a retained third-party one.

The claim’s entire evidentiary basis is a 2020 reader post, not an announcement. User dkhayes117 opened the SiFive-forum thread on 2020-11-21 under the headline “SiFive E2 Series Cores in ESP32-C3!” while quoting nothing but Espressif’s own published C3 feature bullets — four-stage pipeline, RV32IMC, 32-bit multiplier and divider, up to 8 breakpoints, up to 16 PMP areas. The SiFive assertion exists only in the headline the poster chose. The thread’s sole attempt at reasoning is reply #4, “Given it has an FPU, it must be the E24 core”, which is factually wrong — the C3’s misa hardwires F = D = 0, i.e. no floating-point unit at all — and SiFive’s own Jim Wilson corrects it two posts later: “the Espressif chips (ESP32-C*) apparently don’t [have an FPU]” (SiFive forums thread).

Here, absence of evidence is the finding. Neither Espressif nor SiFive has ever published a licensing announcement, customer press release, or product-page reference tying the two together. The defensible statement is therefore: the core’s provenance is undisclosed, and every published identifier Espressif controls says “ours”. Whether that means clean-room in the strict engineering sense cannot be proven from public documents either — but “SiFive E2 derivative” should not be repeated as fact.

For contrast, when Espressif does build on recognisable third-party microarchitecture it shows through in the software: the later ESP32-P4 and ESP32-C5 enable their branch predictors by writing MHCR bits RS/BFE/BTB in components/riscv/include/riscv/rv_utils.h, a custom CSR that is not part of any RISC-V standard. Nothing analogous exists for the C3.

Pipeline and microarchitecture

4-stage in-order scalar pipeline. The TRM does not name the four stages explicitly, but the typical layout for a small RV32IMC core of this class is Fetch / Decode / Execute / Writeback (with the memory access folded into Execute via a single-cycle load path on cache hits). Up to 160 MHz core clock, with the maximum being achievable on the C8 speed grade die under typical conditions (TRM §1.2 Features).

ISA: RV32IMC plus Zicsr and Zifencei. The misa CSR is hardwired: MXL=1 (XLEN=32), I=1 (base RV32I), M=1 (multiply/divide), C=1 (compressed), U=1 (user mode implemented), S=0 (supervisor not implemented), N=0 (user-level interrupts not supported), F=D=E=A=0 (no float, no RV32E, no atomics) (TRM §1.4.2 Register 1.6 misa). For the full ISA breakdown see RV32IMC and Zicsr Extension.

Privilege: M and U only. No supervisor mode. The mstatus.MPP field has only two legal values: 0x0 (User) and 0x3 (Machine); the high MPP bit is hardwired to the low bit (TRM §1.4.2 Register 1.5 mstatus). This matches what is needed for a microkernel-class system: a kernel in M-mode and user processes in U-mode, with the PMP enforcing isolation. See RISC-V Privilege Modes for the broader picture.

Trap vector: vectored-only. The mtvec CSR’s MODE field is read-only 0x1, meaning only RISC-V’s vectored trap mode is supported. The BASE field provides the top 24 bits of a 256-byte-aligned trap-vector base, and interrupt n jumps to base + 4*n (TRM §1.4.2 Register 1.7 mtvec; §1.5.2 Functional Description, Table 1.5-1). This eliminates a layer of software dispatch but constrains software design: each interrupt handler must fit in the 4-byte slot (typically a j handler_n instruction) or use the slot as a jump-table entry.

Physical Memory Protection

The PMP block exists but is intentionally non-compliant with the RISC-V Privileged Spec v1.10 in two specific ways:

1. “Static priority i.e. overlapping regions are not supported,” meaning software must ensure that no two enabled PMP regions overlap. If they do, any access matching any enabled region succeeds (effectively an OR of the matching permissions) (TRM §1.8.2).
2. “Maximum supported NAPOT range is 1 GB,” capping the largest naturally-aligned-power-of-two region (TRM §1.8.2).

The PMP exposes 16 configurable regions (pmpaddr0 through pmpaddr15, with pmpcfg0 through pmpcfg3 packing the per-region permissions) at the standard CSR addresses 0x3A0-0x3BF (TRM §1.4.1 Register Summary, §1.8.4 Register Summary). Minimum granularity is 4 bytes. PMP is the only memory protection in this chip (there is no MMU); see Physical Memory Protection for the broader picture.

Interrupt controller

The CPU complex includes a custom interrupt controller (INTC), not a standard RISC-V CLINT/PLIC pair. It supports:

• “Up to 31 asynchronous interrupts with unique IDs (1-31)”. note ID 0 is reserved for exceptions (TRM §1.5.1).
• 15 programmable priority levels per interrupt (1 = lowest, 15 = highest); a global priority threshold masks below-threshold IRQs (TRM §1.5.2).
• Both level- and edge-triggered sources.
• 4-cycle steady-state latency from interrupt assertion to CPU processing, with up to 5 user-level instructions retiring before preemption (TRM §1.5.3.1).
• Up to 8 hardware breakpoints/watchpoints via the trigger module (TRM §1.2 Features, §1.7).

Memory organisation

The CPU sees three address regions (TRM §1.3 Address Map):

Region	Range	Use
IRAM	0x4000_0000 – 0x47FF_FFFF	Instruction-bus memory map
DRAM	0x3800_0000 – 0x3FFF_FFFF	Data-bus memory map
DM	0x2000_0000 – 0x27FF_FFFF	Debug module
AHB	everything else	Peripherals via AHB

The on-chip memories are 400 KB Internal SRAM, 384 KB Internal ROM (mask ROM, holds boot stub and ROM API functions), and 8 KB RTC FAST Memory (persistent across deep sleep) (TRM §3.2, §3.3.2). The datasheet confirms identically: “ROM: 384 KB; SRAM: 400 KB (16 KB for cache); SRAM in RTC: 8 KB” (Datasheet v2.4 page 4).

Cache

The cache is one of the more subtle points of the ESP32-C3 architecture, and the chip is often misdescribed as having a 16 KB I-cache. The TRM is precise: “ESP32-C3 has a read-only uniform cache which is eight-way set-associative, its size is 16 KB and its block size is 32 bytes. When cache is active, some internal memory space will be occupied by cache (see Internal SRAM 0 in Section 3.3.2)” (TRM §3.3.3.2 Cache). Three facts to note:

1. Uniform, not split I/D. The cache serves both the instruction bus and the data bus, but only one of them per cycle: “the uniform cache is accessible by the instruction bus and the data bus at the same time, but can only respond to one of them at a time” (TRM §3.3.3.2).
2. Read-only and exclusively for external flash. The cache fronts the MMU that maps external flash into the CPU’s IRAM/DRAM virtual windows. On-chip SRAM does not go through this cache (single-cycle zero-wait access per the TRM features list); the cache exists because off-chip QSPI flash accesses cost many CPU cycles per fetch and need to be amortised.
3. The 16 KB is carved out of the 400 KB SRAM. “SRAM: 400 KB (16 KB for cache)” (Datasheet v2.4 page 4). Effective user-available SRAM is 384 KB once the cache claims its share.

The cache supports invalidate, preload, lock/unlock, and prefetch operations; preload and lock can be used to pin hot routines or data into the cache for deterministic latency, which matters for real-time applications running from external flash (TRM §3.3.3.2 Cache Operations).

Multiplier and Divider

The M-extension is hardware-backed. The TRM does not publish per-cycle latency in the parts of the document fetched, but the chip is widely characterized as a single-cycle multiplier with a multi-cycle iterative divider; secondary documentation (NuttX ESP32-C3 platform page; community reverse-engineering) agrees with that pattern, which is standard for area-optimised in-order RV32IMC cores (Apache NuttX ESP32-C3 platform docs).

Wireless: Wi-Fi 4 plus Bluetooth 5 LE

The radio subsystem shares one 2.4 GHz analog path between Wi-Fi and Bluetooth with hardware coexistence. Per the datasheet (v2.4 Features pages 3-5):

Wi-Fi: 802.11 b/g/n (this is “Wi-Fi 4,” the highest IEEE generation supported; the C6 sibling chip adds Wi-Fi 6). 2.4 GHz band only, 20 MHz and 40 MHz channel widths, 1T1R single-spatial-stream up to 150 Mbps, WMM, A-MPDU/A-MSDU aggregation, Block ACK, 4 virtual interfaces, simultaneous Station + SoftAP, 802.11mc FTM for ranging.

Bluetooth 5 Low Energy: BLE 5 with BLE Mesh; PHY supports 125 Kbps, 500 Kbps, 1 Mbps, 2 Mbps; advertising extensions and multiple advertisement sets; high-power mode up to +20 dBm; -105 dBm receiver sensitivity at 125 Kbps. The “Bluetooth 5 (LE)” designation in the product brief is precise: the chip implements BLE 5, not classic Bluetooth (Espressif ESP32-C3 product page).

RF front end: integrated antenna switch, RF balun, PA, and LNA. Output power up to +21 dBm for 802.11b, +20 dBm for 802.11n. A single antenna port; the user-PCB chooses between an on-package antenna trace, a PCB antenna, or a U.FL connector.

Security: eFuse, Secure Boot V2, Flash Encryption

The security subsystem is the chip’s main differentiator over the older ESP8266 and a primary reason for its uptake in consumer IoT:

• eFuse: 4096 bits of one-time-programmable memory, of which 1792 bits are exposed for user data; the rest hold secure-boot keys, flash-encryption keys, MAC addresses, calibration data, and factory configuration (Datasheet v2.4 page 4; TRM Chapter 4 eFuse Controller).
• Secure Boot V2: RSA-3072 signature verification chain rooted in eFuse-burned public key digests. The chip’s official ESP32-C3 product page describes it as “RSA-3072-based secure boot” (Espressif ESP32-C3 product page). The first-stage ROM bootloader verifies a second-stage bootloader against an immutable public-key hash; the second-stage verifies the application; revocation keys allow rotation of compromised keys without bricking the device.
• Flash Encryption: AES-128 or AES-256 in XTS mode encrypts the contents of external flash so that bus-snooping or chip-removal attacks cannot recover plaintext code or data (Datasheet v2.4 Security features; Espressif product page).
• Crypto accelerators: AES-128/256 (FIPS PUB 197 conformant), SHA accelerator (FIPS PUB 180-4), RSA accelerator with modular exponentiation, HMAC, digital-signature peripheral (combines HMAC with RSA), RNG. Clock-glitch detection rounds out the side-channel mitigations (Datasheet v2.4 Security features).

Peripherals: The Rest of the SoC

• GDMA: 3 transmit + 3 receive channels, shared by SPI2, UHCI0 (which bridges UART0 and UART1), I²S, AES, SHA, and the ADC (TRM §2.1 GDMA Overview).
• Two UARTs, three SPIs, I²C, I²S.
• Full-speed USB Serial/JTAG: a built-in USB controller exposes both a USB-CDC serial port for console traffic and a JTAG bridge for debugging, eliminating the need for a separate USB-to-serial chip on the host PCB.
• TWAI controller, ISO 11898-1 compliant (CAN Specification 2.0).
• LED PWM with 6 channels.
• Remote control peripheral (RMT) with 2 transmit + 2 receive channels, useful for IR remote codes and addressable LED protocols.
• Two 12-bit SAR ADCs (6 channels total) and a temperature sensor.
• Timers: two 54-bit general-purpose timers, three digital watchdogs, an analog watchdog, an XTAL32K watchdog, and a 52-bit system timer.
• Programmable GPIOs: 22 pins for the C3, C3FN4, C3FH4, C3FH8X variants (3 of which are strapping pins; 6 are dedicated to in-package flash on the F-suffix variants), or 16 pins for the C3FH4X / C3FH4AZ (Datasheet v2.4 Peripherals page 4).
• Power management: four modes (Active, Modem-sleep, Light-sleep, Deep-sleep). Deep-sleep current is 5 µA; RTC memory remains powered (Datasheet v2.4 Power Management page 5).
• CoreMark: 483.27 at 160 MHz, 3.02 CoreMark/MHz (Datasheet v2.4 page 3). Useful as a calibration point: it is roughly half the CoreMark/MHz of an ARM Cortex-A55, and on par with Cortex-M4 / SiFive E31 class cores.

ESP32-C3 in the ESP32 Family

Espressif’s product line has fragmented around CPU architecture and radio capability. The currently shipping members (Espressif SoC product list):

• ESP32 (2016, original). dual-core Xtensa LX6, Wi-Fi 4, Bluetooth Classic + BLE 4.2. Not RISC-V.
• ESP32-S2 (2019). single-core Xtensa LX7 at up to 240 MHz, Wi-Fi 4, no Bluetooth. Not RISC-V.
• ESP32-S3 (2020). dual-core Xtensa LX7 at up to 240 MHz, Wi-Fi 4 + BLE 5. Adds AI accelerators (vector instructions). Not RISC-V.
• ESP32-C3 (2020). this note. Single-core RV32IMC, Wi-Fi 4 + BLE 5.
• ESP32-C6 (2022). single-core RV32IMC at up to 160 MHz plus a separate ultra-low-power RV32 core. Wi-Fi 6 (802.11ax), BLE 5, 802.15.4 (Thread/Zigbee). The C3’s successor on the radio side.
• ESP32-H2 (2022). single-core RV32IMC, no Wi-Fi, BLE 5, 802.15.4. Designed for Thread/Zigbee/Matter-only applications.
• ESP32-P4 (2024). dual-core RV32IMAFC with a hardware FPU at up to 400 MHz, no radio. Aimed at HMI applications (LCD, MIPI-DSI/CSI, USB 2.0 HS), where a radio-less higher-performance MCU is preferable.

The C3 sits as Espressif’s cheapest mainstream Wi-Fi-and-Bluetooth RISC-V chip. The C6 supersedes it for new designs that need Wi-Fi 6 or 802.15.4; the H2 fills the radio-restricted-to-Thread niche; the P4 covers compute-heavy radio-less HMI work; the S-series remains for backward-compatible Xtensa.

Dev Boards: DevKitM-1 and DevKitC-02

The two Espressif reference boards target slightly different use cases.

ESP32-C3-DevKitM-1. Built around the ESP32-C3-MINI-1 (PCB antenna) or MINI-1U (U.FL connector) module. The MINI-1 module integrates the bare ESP32-C3 chip, a 40 MHz crystal, and a 4 MB SPI flash on a 13.2 × 16.6 mm module. The DevKitM-1 board adds a CP2102N USB-to-UART bridge, a USB-Micro connector, an LDO, and 2×15-pin headers. Compact; meant for space-constrained prototyping (Espressif DevKitM-1 user guide).

ESP32-C3-DevKitC-02. Built around the larger ESP32-C3-WROOM-02 module (18 × 25.5 mm), with 4 MB SPI flash and a slightly more rugged enclosure. Includes a USB-to-UART bridge “providing transfer rates up to 3 Mbps,” 22 GPIOs exposed on dual headers, RGB indicator LED, and reset/boot buttons (Espressif DevKitC-02 user guide; esp-dev-kits docs). Slightly larger form factor, breadboard-friendlier.

Both boards run the same chip, the same SDK, the same firmware. The distinction is purely physical: WROOM-02 for breadboard or rugged prototypes, MINI-1 for embedded targets where the module gets soldered into a product PCB.

Software Stacks

• ESP-IDF, Espressif’s reference SDK, is the canonical environment: FreeRTOS underneath, with thick driver layers for every peripheral, the Wi-Fi/Bluetooth stacks as binary blobs, and a CMake-based build system (Espressif ESP-IDF API reference).
• Apache NuttX supports the ESP32-C3 as an upstream platform (NuttX ESP32-C3 platform docs).
• Zephyr has an ESP32-C3 board definition with full Wi-Fi/BLE support via Espressif’s binary blobs.
• The Rust embedded ecosystem targets the chip via esp-hal and esp-wifi, using the riscv32imc-unknown-none-elf target. The embassy-rs async-runtime works.
• ESP Privilege Separation is an Espressif experiment in running a userspace under M-mode firmware, exploiting the PMP and M+U privilege model to give a small kernel-style isolation guarantee on bare ESP32-C3 silicon (ESP Privilege Separation Architecture docs). The project is the most direct reference for what a microkernel on this chip would look like.

Why It’s the definitely-not-esp32 Benchmark

The project’s name is a deliberate pun: the goal is to build not the ESP32-C3 (i.e. build a from-scratch RV32IMC SoC and microkernel), but to benchmark against the ESP32-C3 honestly. The match is intentional:

• Same ISA (RV32IMC plus Zicsr).
• Same privilege model (M+U only, no S).
• Same memory protection mechanism (PMP, 16 regions, with the project’s implementation conforming to the spec where the ESP32-C3 deviates).
• Same single-cycle multiplier / iterative divider pattern.
• Same trap-handler architecture (vectored mtvec, though the project allows software to choose direct vs vectored).
• A comparable SoC footprint: UART, timer, GPIO, on-chip SRAM, external flash.
• Wildly different process technology (65 nm ASIC for the C3 vs ~55 nm FPGA fabric on the Tang Nano 20K), but that is the project’s interesting handicap, not an apples-to-oranges defect.

Benchmarks the project intends to run on both: a CoreMark-style synthetic loop (the C3 hits 483 at 160 MHz; the project’s softcore at 50 MHz will hit something like 100, the gap dominated by the clock-frequency ratio), an interrupt-latency micro-benchmark (the C3’s 4-cycle INTC latency is a hard target), an IPC round-trip ping-pong between two user tasks, and a UART throughput test. Both the C3 and the project’s kernel will be running the same C code wherever possible, with assembly only at the trap-entry and context-switch points.

Production Notes

• Volume. The ESP32-C3 is among the highest-volume RISC-V chips shipped to consumers, with billions of units across the broader ESP32 family in IoT devices, smart-home products, and industrial sensors (Espressif company materials; Hackaday 2021 launch coverage). It is in Matter-certified products, in commercial smart switches, in BLE beacons.
• Package variants. ESP32-C3 (bare), ESP32-C3FN4 (4 MB SiP flash, EOL), ESP32-C3FH4 (4 MB SiP flash), ESP32-C3FH4AZ (4 MB, NRND status as of datasheet v2.4), ESP32-C3FH4X (4 MB, currently recommended), ESP32-C3FH8X (8 MB) (Datasheet v2.4 page 1). The “F” prefix indicates in-package flash via SiP; “X” / “Z” are pinout / process variations Espressif has rolled out over the years.
• Errata. The TRM is v1.4 as of the current download; Espressif publishes errata separately for each chip revision. Notable historic errata included a Bluetooth power-control issue corrected in chip revision v0.3 and a Wi-Fi PHY calibration improvement in v0.4. Anyone targeting production should check the latest errata document.
• Modules. Espressif sells ESP32-C3-MINI-1, MINI-1U, WROOM-02, WROOM-02U modules; these are the building blocks of the dev kits and also the chips third-party vendors put into their own products. Module datasheets cover crystal accuracy, antenna gain, regulatory certifications.
• For definitely-not-esp32: the project will use a DevKitC-02 as the reference board for benchmark runs (chosen over DevKitM-1 because the breadboard-friendly header layout suits the bench setup). Bench wiring: USB for power and ESP-IDF console; a UART loopback from one of the C3’s spare UARTs back to the host for the throughput test; an oscilloscope on GPIO toggles to validate interrupt latency. The project’s Tang Nano 20K board sits next to it on the same bench, running the same benchmarks; the blog series compares the two side by side.

See Also

• RV32IMC
• RISC-V Privilege Modes
• Physical Memory Protection
• Classic Five-Stage Pipeline
• Branch Prediction
• System on a Chip
• Tang Nano 20K
• Control and Status Registers
• RISC-V Trap Handling
• ecall Instruction
• Computer Architecture MOC