Repository navigation
feat(dfu): boot the app after 6 minutes of DFU inactivity - #88
Conversation
|
No actionable comments were generated in the recent review.
 |
| Layer / File(s) | Summary |
|---|---|
Timer and timeout behavior lib/sdk11/components/libraries/bootloader_dfu/bootloader.h, lib/sdk11/components/libraries/bootloader_dfu/bootloader.c, README.md, changelog.md |
Adds the dfu_activity() API and a one-second timer that tracks idle time. At six minutes, the timer submits DFU_TIMEOUT only if an update is ongoing and a valid application exists. The documentation describes the timeout and continued DFU behavior when no valid application exists. |
Activity event sources lib/sdk11/components/libraries/bootloader_dfu/dfu_transport_ble.c, lib/sdk11/components/libraries/bootloader_dfu/dfu_transport_serial.c, src/usb/msc_uf2.c, src/usb/usb.c |
BLE connection and DFU events, serial DFU packets, UF2 reads and writes, and USB mounting call dfu_activity(). |
Priority:
Estimated code review effort: 3 (Moderate) | ~20 minutes
Change: Feature
Sequence Diagram(s)
sequenceDiagram
participant BLE as BLE transport
participant Serial as Serial transport
participant USB as USB callbacks
participant Activity as dfu_activity()
participant Timer as Inactivity timer
participant Bootloader as Bootloader
BLE->>Activity: Report connection or DFU event
Serial->>Activity: Report DFU packet
USB->>Activity: Report mount or UF2 request
Activity->>Timer: Mark activity
Timer->>Timer: Reset idle count on next tick
Timer->>Bootloader: Submit DFU_TIMEOUT after six idle minutes if update and application conditions hold
Suggested reviewers: rcarteraz, oltaco
Merge Risk: 
53134
-
No actionable timeout issue remains. The change is ready to merge after normal checks.
Pre-merge checks: 
-
Check name Status Explanation Resolution Docstring Coverage Docstring coverage is 60.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 10 functions across 6 files. (2 skipped: … Write docstrings for the functions missing them to satisfy the coverage threshold. -
Check name Status Explanation Description Check Check skipped - CodeRabbit’s high-level summary is enabled. Title check The title clearly and concisely describes the main change: booting a valid application after six minutes of DFU inactivity. 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.
Full details: Docstring Coverage
-
Explanation
Docstring coverage is 60.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 10 functions across 6 files. (2 skipped: 2 unsupported.)
Resolution
Write docstrings for the functions missing them to satisfy the coverage threshold.
-
- 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.
A rabbit watches seconds hop,
While BLE and USB mark each stop.
Serial packets join the queue,
The idle count starts fresh anew.
Six quiet minutes, then boots the app,
If one is valid—no DFU nap.
Comment @coderabbitai help to get the list of available commands.
Checklist
tools/build_all.py(or CI's board matrix) passesDescription of Change
A board with a working app that lands in DFU and then sees nothing, such as a buttonless BLE OTA the phone never starts or
--enter-dfuwith no file copied, waits forever. Now a DFU session that stays idle for 6 minutes with a valid app ends through the existingDFU_TIMEOUTpath and boots the app. A BLE connect, any DFU control or packet event, MSC read or write, USB mount and serial DFU traffic restart the count; with no valid app the board keeps waiting as in 2.6. Same idea as Adafruit'sefe383d, wired intobootloader_dfu_startas a 1 s tick instead of their single-bank erase loop. An idle BLE link with no DFU writes does not count as activity.Tested on the Wio Tracker L1 (S140 7.3.0) with a 30 s test build: BLE wait booted the app at 30.4-30.7 s 3 of 3 and once on battery, the UF2 drive left at 31.9 s 2 of 2, a connect restarted the count 3 of 3, two 250 s BLE OTAs and a 66 s throttled UF2 copy completed, MSC writes with 20 s gaps kept the drive up, and with no valid app it stayed in BLE wait and on the drive past 150 s. The production build booted the app from BLE wait at 361 s; on the drive it left at 423 s twice, a host access about a minute after mount restarting the count.
Summary by CodeRabbit