Over-the-air (OTA) firmware updates are now a standard requirement for connected embedded products — smart home panels, industrial HMIs, automotive infotainment systems, and medical devices all require the ability to update software and assets in the field without physical access to the device. For embedded systems with GUI displays, OTA updates present specific challenges beyond basic firmware replacement: GUI assets (fonts, images, animations, screen layouts generated by Flint) are stored separately from the application firmware and must be updated independently without corrupting the display during or after the update. This guide covers the architecture for safe, robust OTA updates in embedded GUI systems.
Why GUI Assets Require Special Handling in OTA Updates
Standard firmware OTA treats the device's flash memory as a single binary to be replaced. Embedded GUI systems complicate this for several reasons:
- Asset size: GUI assets — images, fonts, animation frames — can be large relative to the application binary. A typical automotive cluster application binary might be 200 KB; its image assets might be 2–8 MB. Updating the full asset pack every time the application firmware changes wastes bandwidth and extends update windows unnecessarily.
- Independent update cadence: Brand rebranding changes only GUI assets (new logo, new colour scheme) without touching firmware. Firmware bug fixes may not touch any GUI assets. Independent update cadence for firmware vs assets reduces the size of each individual update payload.
- Asset-firmware compatibility: GUI assets generated by Flint UI Designer are tied to the specific version of the GUI framework they were generated for. If firmware is updated to a new Sparklet version, assets must be regenerated and updated simultaneously. The OTA update must atomically commit both the firmware and the compatible assets together, or roll both back together.
- Rendering during update: If an OTA update begins while the device is in active use, the display must continue rendering from the current asset set until the update is complete and validated. Writing new assets to flash while the current assets are actively being rendered from the same storage region would corrupt the display.
GUI Asset Storage Strategies
Choose an asset storage architecture before implementing OTA. The choice affects both the OTA complexity and the runtime asset access pattern:
Strategy 1: Assets in a Dedicated Flash Partition
Allocate a dedicated partition in the device's flash memory for GUI assets. The firmware addresses assets by offset within this partition (or by a flash-resident asset index table). The OTA system updates this partition independently from the firmware partition.
Advantages: Clean separation of firmware and assets; firmware binary size is independent of asset size; asset-only updates are small.
Disadvantages: Asset partition size must be allocated at design time; if asset requirements grow beyond the allocated partition size, a complete flash layout change is required.
Strategy 2: Assets Embedded in Firmware Binary (Linked)
Assets are compiled into the firmware binary as C arrays (uint8_t arrays in a .c file) and linked at firmware build time. The OTA system updates a single firmware+assets binary.
Advantages: Simplest architecture — no asset partition management; asset-firmware compatibility is guaranteed (they are always in the same binary).
Disadvantages: Asset-only updates require a full firmware reflash; binary size scales with asset set, which can be significant; limits the asset quantity that fits within the firmware binary size budget.
Strategy 3: Assets in External Flash with Index Table
Assets are stored in an external SPI or QSPI flash device, addressed through an index table in internal flash. The OTA system can update the external flash asset store independently from the internal flash firmware. The index table maps asset IDs to flash offsets.
Advantages: Near-unlimited asset storage (external flash up to 128 MB); assets can be updated or expanded without touching internal flash firmware.
Disadvantages: External flash access latency (SPI read latency vs internal flash); requires external flash component; OTA update must handle both internal firmware and external flash assets, potentially across two separate update channels.
A/B Partition Design for Safe GUI Updates
The A/B (active/inactive) partition scheme is the industry-standard approach for safe OTA updates in embedded systems. Apply it to both firmware and GUI assets:
Firmware A/B Partitions
Two firmware partitions (A and B) of equal size are allocated in internal flash. At any time, one is the active running firmware and the other is the inactive slot. OTA writes new firmware to the inactive slot, validates it, and on success marks it as the next boot slot. The bootloader checks the boot flag on reset and loads from the indicated slot.
Asset A/B Partitions
Similarly, two asset partitions (A and B) hold the current and candidate asset sets. The active firmware slot references the active asset slot through a slot index stored in a small configuration region of flash. OTA writes new assets to the inactive asset slot, then atomically updates the slot index only after successful firmware validation.
Atomic Commit
When firmware and assets must be updated together (new Sparklet version + regenerated assets), the OTA system must commit both atomically:
- Write new firmware to inactive firmware slot → validate
- Write new assets to inactive asset slot → validate
- Atomically update the boot flags to point to the new firmware slot AND the new asset slot together
- Reset to new firmware
Only step 3 changes the active running configuration. If the device loses power during steps 1 or 2, the next reset continues booting from the old firmware and old assets unchanged. If step 3 is interrupted (flash write torn at power loss), the bootloader must detect the incomplete flag update and revert to the previous valid state.
OTA Update Protocol Design
The OTA update protocol defines how new firmware and assets are delivered to the device. For connected embedded products, common approaches:
- HTTPS pull model: The device periodically checks an OTA server for available updates (version manifest). If a newer version is available, the device downloads the update package directly from the server. This is the most common model for consumer and IoT devices — the device initiates the download, which is firewall-friendly.
- MQTT push notification + HTTPS download: The OTA server sends a lightweight push notification (MQTT message) to the device when an update is ready. The device responds by pulling the update via HTTPS. Common in industrial and fleet management applications where the operator controls exactly when updates are pushed.
- Local update via USB/SD card: For devices without network connectivity, or for manufacturing and field service workflows, the update package is delivered on removable media. The bootloader or a dedicated update application detects the media, validates the package, and performs the update.
Regardless of delivery mechanism, the update package structure should include: firmware binary (or delta patch), asset binary (or delta patch), manifest file (version numbers, checksums, firmware+asset compatibility version), and a package signature for authenticity verification.
Delta Updates: Reducing OTA Payload Size
For devices with constrained bandwidth (cellular-connected industrial devices, low-throughput IoT) or large asset sets, delta update techniques significantly reduce OTA payload size. Instead of transferring the full new binary, only the difference (delta/patch) between the current and new version is transferred, and the patch is applied on-device to produce the new binary.
Common embedded delta update algorithms:
- bsdiff/bspatch: Byte-level binary differencing. Effective for firmware binaries where small code changes result in small patches. bspatch applies the patch in memory, which requires RAM equal to the output binary size — may not be feasible on RAM-constrained MCUs.
- VCDIFF (RFC 3284): A standardised delta compression format with streaming decoder support. More memory-efficient than bsdiff for constrained targets. Used by the Janpatch and Courgette tools.
- Asset-specific delta: For image assets, image-format-aware delta (delta at the pixel/block level after PNG decompression) can be significantly more efficient than byte-level binary delta on compressed image data.
Delta updates add complexity to the OTA system: the on-device patcher must run reliably within the available RAM, and the OTA server must maintain the current device firmware/asset version to generate the appropriate delta. If the device's current version is unknown (or the device is heterogeneous across the installed base), full package updates may be simpler to manage than maintaining delta chains for every version combination.
Rollback and Recovery
A device that fails to boot after an OTA update must automatically revert to the previous known-good firmware and assets. Implement a watchdog-based rollback mechanism:
- Bootloader marks the new firmware slot as "pending validation" on first boot after OTA
- Application boots from the new firmware slot
- Application performs a health check: GUI initialises successfully, display renders, communication stack is responsive
- If health check passes within a timeout (e.g., 30 seconds), application calls the OTA manager to mark the new slot as "validated" — the rollback window closes
- If health check fails, or the application crashes within the rollback window, the hardware watchdog resets the device and the bootloader reverts to the previous slot
The rollback mechanism must survive complete application crashes (watchdog timeout), assertion failures, and hard faults — not just graceful error handling. The only safe way to guarantee this is with a hardware watchdog timer that is only reset by the application after successful health check completion.
Update Progress Display
During an OTA update, the display should show the user a clear progress indication — what is happening and how long it will take. Design requirements:
- Display must continue rendering throughout the download and flash write phases (the user must be able to see the device is working, not frozen)
- The GUI must not transition screens or respond to user input during a flash write operation that must not be interrupted
- Progress should be shown as a percentage (download progress, flash progress) not just a spinner — a percentage reduces user anxiety about the update duration
- The display must show a clear "Do not power off" warning during flash write phases where power interruption without A/B rollback protection could brick the device
OTA Asset Loading in Sparklet
Sparklet's asset access layer is designed to support OTA asset updates through a configurable asset storage backend. Assets are referenced by asset ID, not by hardcoded flash address — the asset storage backend resolves IDs to the correct flash location based on the active slot index. When the OTA system switches the active asset slot, Sparklet's asset backend automatically loads assets from the new slot on the next access, with no application code changes required.
Explore Sparklet's embedded GUI architecture that supports OTA-friendly asset management, see platform integration for OTA-capable platforms, or request the evaluation package to begin OTA-capable embedded GUI development.