Signed MCU updates for Zephyr and FreeRTOS

Microcontroller updates have a different failure boundary from Linux updates. There is no package manager to repair a partial install. Memory is limited. A device may lose power during a write, disappear from the network, or boot an image that passes a signature check but cannot run the product.

The public Meshanics MCU SDK now supports two integration paths for ESP32-S3 products:

• Zephyr with MCUboot
• ESP-IDF with its FreeRTOS runtime and native A/B application slots

Both paths use the same compact signed release verifier and the same anti-rollback decisions. The transport and bootloader code differ, but the authorization contract does not.

What the device verifies

A firmware signature alone does not answer whether a release belongs on a particular device. The Meshanics manifest binds the firmware digest and size to the tenant, product, release, rollout, artifact stream and hardware profile.

Before an image is selected for boot, the device checks:

1. The Ed25519 signature against its pinned tenant release key.
2. The product, artifact and hardware profile against local provisioning.
3. The complete SHA-256 digest while firmware is streamed into the inactive slot.
4. The monotonic release counter against its last accepted version.

The implementation uses bounded buffers and does not need a general-purpose JSON library on the device. The portable verifier is tested with the same valid and invalid schema-v2 vectors used by the control plane.

Each device creates its own identity

The console produces a versioned provisioning bundle for a bounded batch. On first boot, the SDK generates a P-256 private key and certificate signing request on the device. The claim service returns a device certificate, then the device uses mutual TLS to retrieve and pin the tenant release key.

The private key does not pass through the control plane. The reusable SDK does not persist the batch claim token. Production teams still need to place the provisioning bundle through a protected manufacturing path and enable encrypted credential storage for their hardware.

A boot is not a successful update

The new application remains a candidate until the product says it is healthy. The integration supplies a bounded health callback for the conditions that matter on that device, such as a sensor becoming ready or a control task starting.

On Zephyr, MCUboot provides the swap and confirmation boundary. On ESP-IDF, the SDK uses the native OTA data partition and rollback state. In both cases, pending release state is stored before the next boot slot is selected. A candidate that does not reach confirmation returns to the previous application, and the failed version is reported to the control plane after recovery.

A valid signature proves who authorized the bytes. The application health decision determines whether those bytes can operate the product.

FreeRTOS support scope

The supported FreeRTOS target is ESP-IDF on ESP32-S3. It is not a claim that one binary works across every vendor FreeRTOS board support package. Network, flash, crypto and boot recovery APIs differ enough that each platform needs a real adapter and product-specific qualification.

For either runtime, qualify the exact board, partition layout, network transport, bootloader policy and recovery behavior used by the product before a production rollout. The qualification should include a successful update, a forced health failure and automatic return to the prior application.

Secure Boot v2 is a separate customer-owned boot signature on ESP-IDF. Teams that require two independent signature boundaries must enable it through their controlled manufacturing process. The development sample does not burn eFuses or silently change that policy.

Try the integration

Create a microcontroller batch in the Meshanics console, choose the Zephyr or ESP-IDF with FreeRTOS runtime, and download the provisioning bundle. The public SDK includes a Zephyr sample, an ESP32-S3 FreeRTOS sample, build instructions and provisioning examples.

Read the Zephyr installation guide or the ESP-IDF and FreeRTOS guide. If you are preparing an MCU product for field updates, we can review the flash layout, health contract and manufacturing trust boundary with you before a pilot.