Firmware updates: USB, BLE, DFU, UF2, and ESP32

LowMesh devices MUST support at least one local update transport. Recommended: USB and BLE together.

MCU families differ; this page names normative expectations per platform so companion tools and factory scripts do not guess.

Transports

Transport	Profile	Notes
USB CDC	Bulk or vendor-specific IN/OUT	Highest throughput; factory use
BLE GATT	Nordic UART Service compatible or custom 128-bit UUID	Field-friendly; slower

Both transports carry the same update envelope bytes (implementation-defined framing) but MUST preserve ordered delivery on BLE (use ATT MTU negotiation and length prefixes).

Nordic DFU

For Nordic SoftDevice–based stacks:

• Use Nordic DFU over BLE or USB serial as supported by the Nordic SDK / MCUboot port.
• Mesh firmware SHOULD pause RF during flash write windows or use dual-bank slots to avoid bricking routing.

States

1. UPDATE_PREPARE — verify signature, erase slot.
2. UPDATE_CHUNK — streamed image.
3. UPDATE_COMMIT — reboot into new image.

Signature algorithms (Ed25519, ECDSA P-256) are implementation policy; document your vendor key in release notes.

Mesh transport vs image signing: CCM-8 (or CCM-4) may protect the mesh transport, but it does not replace firmware image signing. Firmware images MUST be signed independently of LowMesh channel encryption. A valid mesh MIC only proves the transport packet was accepted under a channel key; it does not prove the firmware image is authorized by the vendor.

UF2 for nRF52840

When the MCU is nRF52840 with a UF2 bootloader partition:

• Expose MSC drag-and-drop over USB when the user triggers bootloader mode (double-tap reset, GPIO strap, or CLI command).
• UF2 family ID SHOULD be registered for your product to avoid flashing wrong boards.

Mesh-specific caution

While in UF2 MSC mode, mesh is offline. UI MUST indicate “USB update mode — mesh paused”.

ESP32 (ESP-IDF family)

Espressif devices do not ship a single vendor-standard OTA profile comparable to Nordic DFU across all boards. LowMesh ESP32-class nodes SHOULD implement updates as follows.

Primary (recommended): USB UART + esptool.py

• Factory and developer updates: use the ESP-IDF / esptool workflow over USB serial (CP210x, CH340, built-in USB-JTAG/Serial, or product-specific bridge).
• Images are written to bootloader + partition table + app (and optional OTA data partition) per your partitions.csv.
• Mesh SHOULD pause during flash erase/program windows or use dual OTA slots so routing does not run with inconsistent flash.

This is the default documented path for ESP32 in LowMesh: predictable, scriptable, and independent of mesh availability.

Optional: application OTA (Wi-Fi / HTTPS)

• When the product includes Wi-Fi, firmware MAY use esp_https_ota (or equivalent) to pull a signed image from HTTPS.
• This is not a LowMesh RF feature; document URLs, signing, and rollback in product notes.

Optional: WebUSB / browser flasher

• Host tools MAY use Web Serial (often called “WebUSB” in marketing) to stream the same bytes esptool would send, for convenience installs from a web page.
• Treat as optional; the normative reference remains IDF + esptool for reproducibility.

Optional: BLE chunked OTA (no Espressif standard profile)

• Field-friendly BLE updates on ESP32 are product-defined: e.g. a custom GATT service with length-prefixed chunks, ordered delivery, and resume semantics (similar discipline to the Nordic UART envelope in Transports above).
• If you ship BLE OTA on ESP32, document the UUID, chunk size, signature/checksum, and slot layout alongside releases — do not assume cross-vendor interop.

Mesh-specific caution (ESP32)

Any mode that stops the app or reboots into a download-only UART ROM leaves mesh offline until the new image boots; UI SHOULD mirror the nRF UF2 warning where applicable.

Version reporting

To stay consistent with NODE_ADVERT (see Node identity & advertisement), report firmware and hardware using the same field names as that payload.

Every node advertises these in beacon or status:

Field	Example
fwMajor	1
fwMinor	4
hwBoardId	0x40 for nRF52840

Remote clients use this to decide compatibility with new payload types.

Rollback

Dual-slot designs SHOULD support automatic rollback if the new image fails a self-test within N boots.

Factory reset and key wipe

Factory reset returns the device to a trustworthy provisioning state. Normative rules:

MUST clear

• NMK / networkMasterKey
• Channel PSKs (ChannelSlot table)
• adminChannelPsk
• Contacts and DM session RAM tables
• Bulletin cache (host and client views)
• Local message / file caches and reassembly buffers
• Pairing / session tokens (USB/BLE, remote access)
• shortName / longName and other user-facing labels unless product policy explicitly preserves them for asset tagging

SHOULD preserve

• Hardware calibration (RF trim, antenna compensation)
• Regulatory regionCode and certified RadioProfile, unless the product provides a legal region-selection flow that intentionally resets them
• Bootloader identity and update slots
• Manufacturing serial number / board hwBoardId

Secure wipe

Where flash hardware allows, key material SHOULD be erased or overwritten so it cannot be recovered through normal firmware APIs (multiple-pass or block erase per vendor guidance).

After factory reset, nodeIdentity64 / nodeId32 / Ed25519 keys MAY be regenerated per provisioning policy — document whether identity is preserved in your product manual.

See Embedded storage and Crypto keys.