The firmware side of BLE OTA updates now supports a direct-XIP dual-slot (ping-pong) scheme — see this for full implementation details, testing status, and the app-integration requirements already documented there.
What's needed
- Integrate the OTA transfer toolchain into the app. Firmware-side testing has been done using
wch-ota-tool (a command-line utility) to drive the actual BLE transfer — the app needs equivalent logic built in (or the underlying protocol it implements ported natively), since end users won't have access to a CLI tool. Worth reviewing wch-ota-tool's source/protocol handling as a reference for the exact command sequence and timing that's been validated to work.
- Slot-detection query integration — see linked PR for the exact protocol (
CMD_IAP_INFO), still being finalized/tested on the firmware side, so this can start in parallel but shouldn't be considered locked until that PR confirms it working end-to-end.
- Binary distribution — app needs a way to fetch the correct pre-built binary (of 8 total variants) at OTA time; see linked PR for what's currently available from CI and the open question about long-term distribution (bin branch vs. GitHub Releases).
The firmware side of BLE OTA updates now supports a direct-XIP dual-slot (ping-pong) scheme — see this for full implementation details, testing status, and the app-integration requirements already documented there.
What's needed
wch-ota-tool(a command-line utility) to drive the actual BLE transfer — the app needs equivalent logic built in (or the underlying protocol it implements ported natively), since end users won't have access to a CLI tool. Worth reviewingwch-ota-tool's source/protocol handling as a reference for the exact command sequence and timing that's been validated to work.CMD_IAP_INFO), still being finalized/tested on the firmware side, so this can start in parallel but shouldn't be considered locked until that PR confirms it working end-to-end.