subsys: allow to resume FOTA process#104
Conversation
There was a problem hiding this comment.
Pull request overview
This PR adds support for resuming interrupted Zigbee OTA (FOTA) downloads after reboot by persisting minimal OTA session metadata in Zephyr settings and restoring DFU multi-image progress so downloads can continue from the previous offset.
Changes:
- Add persisted “resume state” (settings) and restore logic to restart an in-progress Zigbee OTA download after reboot/rejoin.
- Extend DFU multi-target writer integration to expose offset/reset hooks needed for progress restore.
- Adjust Kconfig to introduce a resume option and default-enable a settings backend (NVS/ZMS) based on flash type.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 5 comments.
Show a summary per file
| File | Description |
|---|---|
| subsys/lib/zigbee_scenes/Kconfig | Removes direct imply NVS from scenes (backend now handled centrally). |
| subsys/lib/zigbee_fota/src/zigbee_fota.c | Implements settings-backed resume state save/restore and integrates it into OTA/DFU flow. |
| subsys/lib/zigbee_fota/src/dfu_multi_target.c | Adds DFU writer offset/reset hooks (behind save-progress config). |
| subsys/lib/zigbee_fota/Kconfig | Introduces ZIGBEE_FOTA_DOWNLOAD_RESUME option and selects required dependencies. |
| subsys/Kconfig | Adds default backend selection (NVS vs ZMS) when Zigbee scenes/resume are enabled. |
Comments suppressed due to low confidence (1)
subsys/lib/zigbee_fota/src/zigbee_fota.c:604
- The new gap check only rejects
file_offset > current_offset, which allowsfile_offset < current_offset(duplicate/rewound fragments). With the current offset-to-DFU calculation, this can underflow (unsigned wrap) and/or re-write already-flashed data, corrupting the DFU stream. Either restore the strictfile_offset != current_offsetrejection, or explicitly handlefile_offset < current_offsetby skipping already-processed bytes before callingdfu_multi_image_write().
if (ota->upgrade.receive.file_offset > current_offset) {
LOG_WRN("OTA transfer gap. Expected: %d, received: %d",
current_offset,
ota->upgrade.receive.file_offset);
return ZB_ZCL_OTA_UPGRADE_STATUS_ERROR;
}
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Documentation PreviewThe documentation has been built successfully. You can view the preview here: preview Generated at: Expand to view changed pages
|
6b20db7 to
a41800e
Compare
Persist minimal OTA session metadata and reuse DFU progress state so interrupted Zigbee FOTA downloads can resume after reboot. Signed-off-by: Eduardo Montoya <eduardo.montoya@nordicsemi.no>
Enable NVS or ZMS if Zigbe Scenes or FOTA download resume features are enabled. Signed-off-by: Eduardo Montoya <eduardo.montoya@nordicsemi.no>
There was a problem hiding this comment.
LGTM, just one more thing that came to my mind. If someone have used scenes before and will perform the DFU, the settings key name is going to change and data will be lost.
If you think it's a real threat we could do:
- Inform in migration guide that someone needs to set back define to use old key name (easier option)
- Implement auto-migration code that will copy existing entries and assign it with new key names (cool, but more complex and harder to maintain)
Signed-off-by: Eduardo Montoya <eduardo.montoya@nordicsemi.no>
Buffer trailing bytes from Zigbee OTA blocks when synchronous DFU stream writes are enabled. This lets the OTA client consume every received byte while only passing aligned intermediate writes to dfu_multi_image, avoiding early aborts when OTA block boundaries do not match the flash write alignment. Signed-off-by: Eduardo Montoya <eduardo.montoya@nordicsemi.no>
Shorten settings keys names used in the add-on and define all of them in a single header for ease of handling them. Signed-off-by: Eduardo Montoya <eduardo.montoya@nordicsemi.no>
Persist minimal OTA session metadata and reuse DFU progress state
so interrupted Zigbee FOTA downloads can resume after reboot.
KRKNWK-21784