Web flasher

Not yet validated end-to-end

This flasher is built against the release pipeline’s artifact contract (Releases & signing) but there is no public tagged release yet, so it has not been exercised against real published artifacts on real hardware. Until that validation pass happens (tracked for launch), treat it as beta and prefer the CLI fallback if anything looks off. It refuses to write anything that fails a checksum, manifest, or chip-detection test, so the failure mode is “it stops”, not “it bricks”.

Requirements: Chrome or Edge on desktop (the Web Serial API — Firefox and Safari don’t ship it), a USB data cable (some cables only carry power), and a supported board (which one?).

BoardSeeed XIAO ESP32S3 + Wio-SX1262 (field hotspot)Seeed XIAO ESP32S3 + Wio-SX1262 (uplink router)Seeed XIAO ESP32S3 + Wio-SX1262 (USB network)Heltec WiFi LoRa 32 V3Heltec WiFi LoRa 32 V4RAK4631 (nRF52840) — not web-flashable

Channelstable (vX.Y.Z)beta (vX.Y.Z-beta.N)local file (advanced — no verification)1 · Fetch release2 · Connect & flash

Pick a board and channel, then fetch.

What it verifies before writing

Every release attaches per-board images, a SHA-256SUMS file, and a signed 119-byte .lrcmanifest per board (the full story). Before flashing, this page:

1. downloads the merged-flash image for your board and channel and checks its SHA-256 against SHA-256SUMS;
2. decodes the board’s .lrcmanifest and shows you the signed firmware version, board and profile — and refuses to cross-flash if the manifest’s board id doesn’t match the board you picked;
3. cross-checks the manifest’s image hash against SHA-256SUMS;
4. verifies the manifest’s Ed25519 signature against the release public key in-browser, where the browser’s WebCrypto supports Ed25519 (it says so honestly when it can’t);
5. confirms the connected chip family matches the board you selected.

The merged image contains bootloader + partition table + app in one file written at offset 0x0 — no offsets to get wrong.

The ESP32-S3 first-flash quirk

XIAO-class boards (and the Heltec V4, on its first flash) use the ESP32-S3’s native USB-Serial-JTAG — there’s no USB bridge chip driving a hardware reset line. Two consequences, straight from the user guide:

1. First flash onto a board not already running LoRa Relay Chat: hold the BOOT button, plug the cable in (or tap reset while holding BOOT), release BOOT once the port shows up. That forces the ROM bootloader.
2. After flashing: fully power-cycle the board. Flashing reports success, but on these boards the new app does not reliably start until every power source is disconnected and reconnected — a bare USB unplug/replug is enough if the cable is the only power source.

Boards already running LoRa Relay Chat skip all of this: fwupdate on the device console requests download mode in software, and the Heltec V4’s CDC build re-enters it automatically. Heltec V3 has a CP2102 bridge and never needs the dance. The flasher shows the right steps for whichever board you pick — before you flash, not after it fails.

CLI fallback

No Chrome? Every release is just files — flash them with esptool:

# Merged image: the whole flash in one file, offset 0x0.
esptool.py --chip esp32s3 --port /dev/ttyACM0 write_flash 0x0 \
  xiao_wio_sx1262-merged.bin

# Verify what you downloaded first:
sha256sum -c SHA-256SUMS --ignore-missing

Or build from source with PlatformIO: pio run -d firmware -e xiao_wio_sx1262 -t upload. The RAK4631 (nRF52) always takes the CLI path — it uses the Adafruit DFU bootloader, not esptool, and no merged image is published for it. Full instructions including manifest verification with the lrc-manifest tool: user guide.