April 19, 2026 · 2 min read

Three ways home for field firmware

Why a browser flasher, UF2 fallback, and explicit bootloader path are one recovery system rather than redundant conveniences.

Recovery is part of the product

A radio node may be installed far from a familiar toolchain. The update experience therefore has to survive missing drivers, interrupted power, a broken application image, and an operator who has never opened the source tree.

TRANSPORTANNOUNCEACKRECOVERY
Every update path ends at the same verified firmware artifact, but each removes a different field dependency.

The primary browser flasher is the shortest path. UF2 drag-and-drop removes the browser and serial stack. A deliberate command or hardware gesture into the bootloader remains available when the application itself is unhealthy.

textPRIMARY   browser flasher -> verify -> reboot
FALLBACK  UF2 volume      -> copy   -> reboot
RECOVERY  bootloader entry -> flash -> verify

Make the dangerous transition explicit

Updates are not the place for hidden automation. The interface should name the target, version, erase behavior, and recovery option before bytes move.

Evidence after reboot

A successful transfer is not a successful update. The new image has to boot, identify its version, initialize the radio, and stay alive long enough to satisfy the watchdog contract.

  • Verify the artifact before transfer.
  • Keep the bootloader path outside the application image.
  • Report the running version after restart.
  • Exercise every recovery route in release validation.

Redundancy is useful when each route removes a genuinely different dependency.