Repository navigation
Reset into BLE OTA DFU instead of jumping from the DFU callback - #12220
Conversation
The Adafruit BLEDfu handler switches to the main stack and jumps to the bootloader. Since the nRF52 toolchain moved to GCC 12.3.1 (#12027) that call is compiled as a tail call whose epilogue pops the task frame from the main stack, past the end of RAM, and the CPU locks up; the bootloader then starts with GPREGRET 0xB1 and no SoftDevice, faults, and resets into the app. Handle START_DFU here instead: write the same peer data and leave through enterOTADfu(), a reset with the 0xA8 magic that every bootloader handles.
⚡ Try this PR in the Web FlasherNote Building this pull request… the flash button, badges and supported-board |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📝 Walkthrough
Merge Risk: ⚪ Minimal · up to
|
| Check name | Status | Explanation | Resolution |
|---|---|---|---|
| Docstring Coverage |  |
Docstring coverage is 33.33% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 3 functions across 1 files. | Write docstrings for the functions missing them to satisfy the coverage threshold. |
-
Check name Status Explanation Title check The title clearly and concisely describes the primary change: resetting into BLE OTA DFU instead of jumping from the DFU callback. Linked Issues check Check skipped because no linked issues were found for this pull request. Out of Scope Changes check Check skipped because no linked issues were found for this pull request. Description check The description follows the repository template closely. It explains the problem (BLE OTA failing on nRF52 since #12027moved to GCC 12.3.1), the root cause (tail-call epilogue pops the task frame fro…Full details: Description check
-
Explanation
The description follows the repository template closely. It explains the problem (BLE OTA failing on nRF52 since
#12027moved to GCC 12.3.1), the root cause (tail-call epilogue pops the task frame from the main stack), and the fix (handle START_DFU in QuiescingBLEDfu and reset via enterOTADfu() instead of jumping). It links the issue with 'fixes#12196', lists related PRs in other repos, and gives test details on two Seeed Wio Tracker L1 Pro units. The Attestations section is filled in. Only the device checkboxes for the template's standard boards are unchecked; the author explicitly says those boards were not tested. The template's tip block was removed, as required.
-
✨ Finishing Touches: 💡 1
-
📝 Generate docstrings: 💡
-
- Commit to this branch
- Create a new PR
🧪 Generate unit tests (beta)
-
- Commit to this branch
- Create a new PR
-
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.
Comment @coderabbitai help to get the list of available commands.
|
|
LGTM. We should probably test on both SD versions. |
BLE OTA started from the apps fails on nRF52 builds since #12027 moved the toolchain to GCC 12.3.1. The node shows the bootloader's BLE OTA screen and is back in its old firmware about 10 s later; no update can start. USB/UF2 updates are unaffected.
The Adafruit
BLEDfuhandler switches to the main stack (__set_CONTROL(0)) and then callsbootloader_util_app_start(). GCC 9 emits a plainbl; GCC 12 makes it a tail call whose epilogue (add sp, #108; ldmia sp!, {r4-r7, lr}) pops the task frame from the main stack, past the end of RAM, and the CPU locks up. The bootloader then starts with GPREGRET 0xB1 but no SoftDevice, faults on its first SoftDevice call, and resets into the app.QuiescingBLEDfunow handles START_DFU itself: same CCCD check and reply, same peer data at 0x20007F80 (layout asserted, same CRC), thenenterOTADfu(), a reset with the 0xA8 magic, instead of the jump. The bootloader inits the SoftDevice itself and still reconnects to the peer.The same root cause is fixed library-side by blin00 in meshtastic/Adafruit_nRF52_Arduino#8; this change does not depend on it. The bootloader is hardened separately in meshtastic/nRF52_Bootloader#69.
🤝 Attestations
Bisected to #12027 on both units (parent good, #12027 bad on each). With this change, a full BLE update (713 KB, legacy DFU from bleak) completed and booted on an OTAFIX master bootloader without the #69 fix, and the bootloader came up in 1.5 s on the second unit's OTAFIX 2.2-BP1.3 bootloader. Not tested on other boards, on a stock vendor bootloader, or with the Meshtastic Android DFU client.
Summary by CodeRabbit
fixes #12196