Skip to content

Supported Boards

Espilon runs across the ESP32 line. The chip you pick determines which modules are available, how much IRAM the loader has, whether panic isolation works, and which C2 transport is viable in the field.

Chip support

Chip Architecture WiFi BLE PSRAM Firmware config
ESP32 classic Xtensa LX6 dual-core Yes No No configs/esp32
ESP32-C3 RISC-V single-core Yes On-demand No configs/esp32c3
ESP32-C6 RISC-V Yes On-demand No configs/esp32c6
ESP32-S3 v0.2 Xtensa LX7 dual-core Yes No (errata) 8 MB configs/esp32s3-v0.2
ESP32-S3 v0.3+ Xtensa LX7 dual-core Yes Yes 8 MB configs/esp32s3
ESP32-S3-CAM Xtensa LX7 dual-core Yes per silicon 8 MB configs/esp32s3-cam

Capability matrix

Capability ESP32 C3 C6 S3 v0.2 S3 v0.3+
BLE No Yes Yes No (errata) Yes
Panic isolation Yes Reboots Reboots Yes Yes
PSRAM module execution No No No Yes Yes
Approx. IRAM ~128 KB ~256 KB ~256 KB 256 KB + PSRAM 256 KB + PSRAM

Caveats

BLE is on-demand only

BLE is never initialized at boot. NimBLE starts the first time a module calls ble_controller_init(); the first BLE command therefore has extra latency. Initializing at boot would race the high-priority NimBLE task against command registration.

  • ESP32 classic has no BLE in this firmware (insufficient IRAM alongside the stack).
  • ESP32-S3 v0.2 cannot use BLE because of a ROM-level silicon errata. Build with configs/esp32s3-v0.2 (CONFIG_BT_ENABLED=n). There is no workaround on that revision; use S3 v0.3+ or a C6 for BLE.
  • Panic isolation works only on Xtensa (ESP32, S3). On RISC-V (C3, C6) an unhandled module fault reboots the device.
  • PSRAM execution (S3) loads modules to the data bus and runs them via the instruction-bus alias, so the S3 can run much larger modules.

Identify a board's chip and revision before flashing:

python -m esptool chip-id --port /dev/ttyXXX

Specialized boards