ESP32 Development — ESP-IDF, ESP32-S3, ESP32-C3
Production-grade ESP-IDF firmware for Wi-Fi, BLE, and Matter devices — from partition table to regulatory type approval.
What We Build on This Platform
Wi-Fi Station & AP
802.11 b/g/n STA and AP mode, WPA2-Enterprise, WPA3, and configurable power-save modes for battery-operated devices.
BLE 5.0
GATT server and client, advertising, scanning, LE Secure Connections pairing, and BLE Mesh for building automation.
Matter & Thread
Matter 1.x commissioning, Thread border router, and DCL attestation on ESP32-H2 and ESP32-C6.
OTA Update
Dual partition OTA with automatic rollback, HTTPS binary verification, delta update, and ECDSA image signature.
Production NVS & Flash
NVS namespace design, partition table configuration, wear levelling, and flash encryption for production devices.
RF Coexistence
Simultaneous Wi-Fi and BLE operation through the ESP32 coexistence scheduler with tuned priority configuration.
Low-Power & Deep Sleep
ULP coprocessor, RTC GPIO wake source, and deep sleep current below 10µA for battery-operated sensor nodes.
USB & Peripheral
ESP32-S3 USB OTG full-speed, USB CDC, plus UART, SPI, I2C, ADC, RMT, LEDC peripheral configuration.
How Ankh Uses This Platform
Platform Variant Selection
Variant selected from connectivity, processing, USB, and cost requirements before any firmware is written. ESP32 for dual LX6 with Wi-Fi + BLE, ESP32-S3 for dual LX7 with USB OTG and AI vector extensions, ESP32-C3 for compact RISC-V with Wi-Fi + BLE 5, ESP32-H2 for Thread/Zigbee without Wi-Fi, and ESP32-C6 for Wi-Fi 6 with Thread and BLE 5.
ESP-IDF Project Structure
Component architecture established with Kconfig menuconfig for feature gating, CMake build system, IDF version pinning, and toolchain configuration for the specific variant. Partition table designed from the OTA requirement: factory app, OTA_0 and OTA_1 partitions, NVS partition for configuration, and spiffs or littlefs for file data.
Connectivity Stack Configuration
Wi-Fi driver configured for scan parameters, reconnect backoff, power-save mode for battery devices, and BSSID tracking for mobile deployments. BLE stack configured with GAP advertising parameters, GATT service and characteristic definitions, and connection parameters for the target battery life. Coexistence configuration adjusted for the specific combination of Wi-Fi and BLE traffic patterns.
OTA, Security & Production Configuration
OTA update implemented with HTTPS verification of the firmware binary, ECDSA image signature verification before OTA commit, and boot-count watchdog for automatic rollback. Secure boot and flash encryption configured for production. NVS encryption for stored credentials. Efuse programming plan established for production provisioning.
RF Certification & Production
Pre-compliance measurement in the final PCB and enclosure configuration. Antenna type selected from RF performance measurement. FCC Part 15 and CE RED certification path determined for custom module versus pre-certified module. Production flash programming fixture with esptool.py for batch programming and verification.
Deep Technical Capability
Heap Fragmentation in Long-Running ESP-IDF Firmware
The ESP32's dual-heap architecture — DRAM internal heap and optional PSRAM external heap on S3/S2 variants — accumulates fragmentation over runtime in applications that allocate and free variable-size buffers: MQTT message payloads, HTTP response buffers, JSON parse trees. The application that runs correctly for 72 hours and then fails with ESP_ERR_NO_MEM on a malloc that previously succeeded has not run out of memory — it has accumulated fragmentation such that no contiguous block of the required size is available despite the total free heap exceeding the requested allocation. Ankh designs long-running ESP-IDF firmware with heap fragmentation mitigation: static allocation for all fixed-size buffers, ring buffers instead of dynamic-length queues for streaming data, memory pool allocators for fixed-size objects that are frequently allocated and freed, and heap fragmentation monitoring in the production firmware that alerts before heap exhaustion rather than at the moment of failure.
Wi-Fi and BLE Coexistence on the Shared 2.4GHz Antenna
The ESP32's single 2.4GHz RF path is shared between the Wi-Fi and BLE stacks through a time-division coexistence scheduler. Default coexistence configuration allocates time slots dynamically based on the activity of each stack — but default is not optimal for every application. A device that needs sustained BLE notification throughput while maintaining a Wi-Fi MQTT connection to the cloud may find that the default coexistence scheduler starves BLE notifications during Wi-Fi TCP ACK bursts, producing variable notification latency that the mobile app user experiences as connection instability. Ankh characterises the coexistence timing for the specific combination of Wi-Fi and BLE traffic patterns using the coexistence status API and adjusts the coexistence priority settings and TBTT timing from the measurements — not from the default configuration that the ESP-IDF documentation recommends without qualification for all application profiles.
Matter Commissioning and DCL Attestation on ESP32
The ESP32's Matter implementation via the esp-matter SDK requires three elements not provided by the SDK out of the box for production devices: a Device Attestation Certificate provisioned uniquely to each device at manufacturing, a Certification Declaration issued by the CSA after the product passes Matter certification, and a Distributed Compliance Ledger entry that maps the product's VID/PID to the CD and PAA certificate chain. The DAC is a device-unique X.509 certificate signed by a Product Attestation Intermediate whose root is the Product Attestation Authority registered with the CSA. Ankh implements the complete Matter manufacturing provisioning flow: DAC generation from the device's unique identifier, DAC programming into the ESP32's NVS or secure element partition during manufacturing, and DCL registration coordination with the CSA — so every production unit has the device identity that Matter commissioning requires for multi-ecosystem deployment.
Products Built on This Platform
IoT Connected Devices
ESP32-C3 as the primary connectivity SoC for Wi-Fi + BLE dual-mode sensor nodes.
View ProductSmart Home Devices
ESP32-H2 for Thread border router integration and Matter end device in home automation.
View ProductWearable Electronics
ESP32-C3 in compact BLE wearable designs where PCB area constrains SoC selection.
View ProductSmart Agriculture
ESP32 in greenhouse and shed-mounted environmental monitoring nodes with Wi-Fi connectivity.
View ProductAI Vision Systems
ESP32-S3 for local image pre-processing and BLE configuration interface in compact vision nodes.
View ProductFleet Telematics
ESP32 as the secondary connectivity SoC for BLE provisioning and Wi-Fi local data offload.
View ProductProduction firmware, not demo firmware
The ESP32 demo project that connects to Wi-Fi and publishes sensor data in a loop works correctly in the first week of a product pilot. The same firmware running on 5,000 deployed devices at varied Wi-Fi signal levels, with periodic power interruptions, across a 3-year deployment produces heap fragmentation failures, NVS corruption from uncontrolled power loss, and MQTT reconnect storms when many devices simultaneously lose and regain connectivity. Ankh designs ESP-IDF firmware for the failure modes of production deployment — not for the success modes of a development bench.
The antenna design is not the module's antenna design
An ESP32 module with a certified PCB trace antenna achieves its specified radiated performance in the free-space keepout configuration of the module's reference design. The same module installed in a product with a ground plane extension within the antenna keepout, a metal enclosure 5mm from the antenna, or a lithium polymer battery adjacent to the RF section achieves significantly different radiated performance — and the FCC grant for the module does not cover the product's final configuration. Ankh measures the antenna performance of the ESP32 in the actual PCB and enclosure context and designs the matching network correction or antenna placement adjustment from the measurement before the regulatory submission.
IDF version management is a production decision
The ESP-IDF release that a product ships with is not simply the latest stable release at the time of development — it must be maintained across the product's lifetime, its security fixes must be backported or its upgrade path tested against the production firmware, and its component dependencies must be pinned to prevent upstream changes breaking a build. Ankh establishes IDF version pinning, component lock files, and a patch management process for every ESP32 product at the start of firmware development — so the production firmware build is reproducible 3 years after first shipment.