ESP32 Firmware Development (ESP-IDF, OTA, Secure Boot)
ESP-IDF firmware with FreeRTOS tasks, secure OTA, secure boot and flash encryption, planned for the factory
ESP32 firmware development is writing the production software that runs on Espressif's ESP32 family: tasks, connectivity, power management, updates and security. Electuni builds ESP-IDF firmware for product teams shipping Wi-Fi or Bluetooth LE devices, from first bring-up to signed, encrypted builds with secure OTA updates and a defined factory provisioning step.
Design → Prototype → Production
Key Facts: ESP32 Firmware Development
- Chips
- ESP32, S3, C3, C6
- Framework
- ESP-IDF + FreeRTOS
- Connectivity
- Wi-Fi, BLE, MQTT/TLS
- Updates
- A/B OTA with Rollback
- Security
- Secure Boot v2, Flash Encryption
- UI
- LVGL on ESP32-S3
What You Get
- Chip and module recommendation for the product's radios, memory and power budget
- ESP-IDF firmware with a documented FreeRTOS task and event structure
- Partition table sized for A/B OTA, NVS and any data or certificate partitions
- Secure OTA update flow with signature checks and automatic rollback
- Secure boot v2 and flash encryption plan, tested on development boards before release
- Factory provisioning procedure for per-device credentials and configuration
- Source code in Git with build instructions and release notes
How We Approach ESP32 Firmware Development
The ESP32 name covers several chips with different trade-offs, so the first decision is which one. The original ESP32 is a dual-core Xtensa part with Wi-Fi, Bluetooth Classic and BLE. The ESP32-S3 adds vector instructions, native USB and support for octal PSRAM, which makes it the usual choice for touch displays and LVGL interfaces, but it drops Bluetooth Classic. The ESP32-C3 is a lower-cost single-core RISC-V part with Wi-Fi and BLE 5. The ESP32-C6 adds Wi-Fi 6 and an 802.15.4 radio for Thread and Zigbee. The chip is chosen from the product's radios, memory needs and power budget, not from the nearest development board.
Firmware is written in ESP-IDF, Espressif's official framework, on top of its FreeRTOS kernel. Work is divided into tasks with clear priorities and core affinity, and components talk through queues and the ESP-IDF event loop rather than shared globals. Wi-Fi and BLE share one 2.4 GHz radio on these chips and are time-multiplexed when both run, so coexistence is planned up front: for example, BLE provisioning followed by Wi-Fi operation, or reduced BLE activity while large transfers run. Device data is sent over MQTT with TLS, with certificates validated on the device rather than skipped during development and forgotten.
Production readiness is mostly about what happens after the device leaves the bench. The partition table reserves two OTA app slots, NVS for configuration and any certificate or data partitions, sized with headroom for future builds. OTA images are verified before boot, and a new image must confirm itself healthy or the bootloader rolls back to the previous slot. Secure boot v2 and flash encryption are planned early, because both burn one-time eFuses. Finally, a factory step writes per-device credentials and configuration, so every unit leaves the line uniquely identified.
Technical Constraints and Trade-offs
- Wi-Fi and BLE share a single 2.4 GHz radio on ESP32 chips, so running both at once reduces throughput and adds latency for each. Coexistence has to be designed, not assumed.
- Two OTA app slots halve the flash available for the application, so flash size is chosen with the A/B layout and future firmware growth in mind.
- Secure boot and flash encryption are enabled by burning eFuses, which cannot be reversed. Keys and release-mode settings are tested on spare boards before any production unit is locked.
- Deep sleep powers down the CPUs and most RAM, and the chip restarts on wake. Wi-Fi must reconnect after each wake, which often dominates the energy budget of battery products.
- Brownouts during flash writes or radio transmit peaks can corrupt data or cause reset loops, so supply design, the brownout detector level and NVS write patterns are reviewed together.
- LVGL interfaces on the ESP32-S3 usually need PSRAM for frame buffers, and the display interface and buffer strategy set the achievable frame rate.
Fabrication and Assembly Handoff
- Git repository with full history, pinned ESP-IDF version and reproducible build instructions
- Partition table and sdkconfig defaults for development and release builds
- Documented procedure for generating, storing and using the secure boot signing key, without the key itself leaving your control
- Flash encryption and eFuse settings, with the steps used to burn them in release mode
- OTA release procedure, including image signing, version numbering and rollback behaviour
- Factory provisioning script and instructions for writing per-device credentials
From a real project
CHEFFY EGOR: ESP32 control and interface bring-up
EGOR is a breakfast robot operated from one small round front panel. Electuni brought up an ESP32 controller that runs a rectangular TFT LCD behind the round tinted cover lens, reads three tactile buttons through a PCF I2C I/O expander, and drives the stepper motor through an SPI stepper driver, all in one firmware build. Stepper driver control and diagnostic registers were read back onto the screen in real time while step timing was tuned for slow, smooth motion.
Read the project (opens in a new tab)How an Electuni Engagement Works
Step 1
Discovery
Requirements analysis and feasibility study.
Step 2
Architecture
System design, component selection, and risk assessment.
Step 3
Design
Schematic, layout, firmware, and mechanical CAD.
Step 4
Review
DFM/DFT checks and design review with stakeholders.
Step 5
Prototype
Board fabrication, assembly, and firmware bring-up.
Step 6
Handoff
Production files, BOM, and full documentation package.
Tools & Technologies
- ESP-IDF
- FreeRTOS
- esptool / espefuse
- LVGL
- MQTT
- Git
ESP32 Firmware Development FAQ
Which ESP32 chip should my product use?
It depends on the radios, interface and power budget. The ESP32-S3 suits products with a display or camera, thanks to PSRAM support and native USB. The ESP32-C3 suits cost-sensitive Wi-Fi and BLE devices. The ESP32-C6 fits products that need Wi-Fi 6, Thread or Zigbee. The original ESP32 remains relevant mainly when Bluetooth Classic is required.
Do you use ESP-IDF or Arduino for ESP32 firmware?
Production firmware is written in ESP-IDF. It exposes the full configuration of FreeRTOS, partitions, power management, secure boot and flash encryption, and it is maintained with defined release versions by Espressif. Arduino is useful for quick experiments, but a product that needs secure OTA, eFuse configuration and long-term maintenance is better served by ESP-IDF directly.
How does OTA rollback work on the ESP32?
The partition table holds two app slots and an otadata partition that records which one should boot. A new image is written to the inactive slot and booted as pending verification. If the firmware does not mark itself valid, for example because it crashes or cannot reach the server, the bootloader returns to the previous slot on the next reset.
Should secure boot and flash encryption be enabled on every product?
For most connected products, yes. Secure boot v2 ensures only firmware signed with your key runs, and flash encryption protects firmware and stored credentials if someone reads the flash chip. Both are permanent once release-mode eFuses are burned, so they are enabled on development boards first and the key management process is agreed before production.
How long can an ESP32 device run on a battery?
That depends on how often it wakes, how long the radio stays on and the quiescent current of the rest of the board, not just the chip. Deep sleep current is low, but each Wi-Fi reconnection costs significant energy. A power budget is estimated from the duty cycle and then measured on real hardware with a current profiler.
What is factory provisioning on the ESP32?
It is the production step that gives each unit its identity: a device certificate and private key, serial number, cloud endpoint and any calibration data, usually written to a dedicated NVS or certificate partition. Done well, it is scripted and logged, so credentials are never shared between devices and each serial number can be traced.