Repository navigation
Conversation
…SD event handler The core's flash driver now bounds its wait for the SoftDevice flash-completion event and drains the SoC event queue itself while waiting, so a lost completion can no longer park the writing task forever (seen on the nRF54L15-DK: a LittleFS commit during a BLE connection froze the whole firmware, BLE included, and a reset mid-write is what wiped the saved config). Whatever else it pulls out of the queue must get the same treatment as checkSDEvents(), so factor the switch into handleSDEvent() and hand it to the driver's flash_nrf5x_soc_event_hook.
|
Important Review skippedReview was skipped as selected files did not have any reviewable changes. ⚙️ Run configuration
You can disable this status message by setting the Use the checkbox below for a quick retry:
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 25.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 4 functions across 1 files. | Write docstrings for the functions missing them to satisfy the coverage threshold. |
✅ Passed checks (4 passed)
-
Check name Status Explanation Title check ✅ Passed The title clearly identifies the nRF54 fix and the routing of SoC events through the SoftDevice event handler. Description check ✅ Passed The description explains the problem, implementation, compatibility with the core change, testing performed, and hardware limitations. The required attestations are completed, and the untested devices… Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request. Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
✨ Finishing Touches
-
🧪 Generate unit tests (beta)
-
- Create a new PR
-
- Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Autopilot is currently an internal CodeRabbit preview.
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.
⚡ Try this PR in the Web FlasherNote Building this pull request… the flash button, badges and supported-board |
…ents-during-flash-wait
…ents-during-flash-wait
…ents-during-flash-wait
…ents-during-flash-wait
Summary
The Arduino core's flash driver now bounds its wait for the SoftDevice flash-completion event and drains the SoC event queue itself while it waits (meshtastic/nRF54_Arduino#1). On the nRF54L15-DK, a LittleFS commit during a BLE connection used to freeze the whole firmware, BLE included, when that completion got lost; a reset in the middle of the write is what wiped the saved config.
Any other SoC event the driver pulls out of the queue while it waits has to get the same handling as in
checkSDEvents(). This factors the switch intohandleSDEvent()and hands it to the driver's weakflash_nrf5x_soc_event_hook.Without the core change the hook is never called, and the firmware behaves exactly as before, so the two can land in either order.
Testing
nRF54L15-DK + E22-900M30S with the core change, Meshtastic 2.8.1 and 2.8.2, iOS app connected over BLE, on a live mesh: config saves over BLE complete. Every hang captured live since 2026-09-20 (several multi-day soaks) was the GRTC idle hang fixed in the core; none happened in a flash write.
🤝 Attestations
nRF54L15-DK only; the change is in
src/platform/nrf54/.Summary by CodeRabbit