feat(firmware): link OTAFIX bootloader from slow-DFU success screen#5917
Merged
Conversation
Builds on #5915, which detects a low-speed (MTU-capped) nRF52 BLE DFU transfer and shows an in-upload hint naming the OTAFIX bootloader. That hint had no link, leaving users no actionable path to the ~10x speedup. A link can't go on the upload screen: opening a browser backgrounds the app mid-DFU, which can drop the BLE link and brick a half-written image (the screen keeps itself on and traps back-nav for exactly this reason), and you can't flash a new bootloader mid-transfer anyway. So the actionable "Learn more" link lives on the Success screen, shown only when the just-finished transfer was low-speed. FirmwareUpdateState.Success now carries a wasLowSpeedTransfer flag, set from transport.isLowSpeedTransfer and threaded through verifyUpdateResult, so the tip follows the actual negotiated MTU rather than a static per-device guess (a board already running OTAFIX isn't slow). Reuses the existing slow-bootloader-hint and learn_more strings; no new flag. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
#5915 detects a low-speed (MTU-capped) nRF52 BLE DFU transfer — a stock Adafruit bootloader negotiates only ATT MTU 23, capping Legacy DFU at 20-byte packets (~3.7 KB/s; a ~785 KB image takes ~3.5 min). It shows an in-upload hint naming the OTAFIX bootloader, which grants a high MTU (244-byte packets, ~10× faster). But that hint had no link, so users had no actionable path to the fix.
A link can't live on the upload screen: opening a browser backgrounds the app mid-DFU, which can drop the BLE link and brick a half-written image (the screen runs
KeepScreenOnand traps back-nav for exactly this reason), and you can't flash a new bootloader mid-transfer anyway. So the actionable "Learn more" link lives on the Success screen — shown only when the just-finished transfer was low-speed, once it's safe to leave the app and the user has just felt the slowness.Changes
🌟 The firmware-update Success screen now offers a one-time OTAFIX upgrade tip with a "Learn more" link, but only after a slow (MTU-capped) DFU transfer.
🛠️
FirmwareUpdateState.Successnow carries awasLowSpeedTransferflag, set fromtransport.isLowSpeedTransferinSecureDfuHandlerand threaded throughverifyUpdateResult. The tip follows the actual negotiated MTU rather than a static per-device guess (a board already running OTAFIX isn't slow), so no new device flag was added. Reuses the existingfirmware_update_slow_bootloader_hintandlearn_morestrings — no new string resources.The link points at the OTAFIX README because meshtastic.org's nRF52 docs don't yet document OTAFIX or the bootloader-dependent transfer speed (a docs PR upstream would let this point at meshtastic.org later).
Testing Performed
./gradlew spotlessCheck detekt assembleDebug test allTests— all pass.FirmwareUpdateState.Successfor the new data-class constructor; existing post-success state-transition assertions still pass.if (wasLowSpeedTransfer)branch inSuccessState(not separately screenshot-tested). Not yet verified on real OTAFIX 2.1 hardware — only a stock-bootloader RAK4631 was available; confirming the high-MTU path engages on an OTAFIX unit remains a follow-up.