MCUBoot BLE DFU fails due to custom power-on / accidental boot logic intercepting DFU reboots

RE: MCUBoot BLE DFU fails due to custom power-on / accidental boot logic intercepting DFU reboots

Amanda Hsieh — Fri, 23 Jan 2026 21:52:08 GMT

Hi,

Looks like you can go with

1. Set "DFU ion progress" flag whenever you receive an image.

2. If you know the image confirmation sequence, you might clear the flag in the last confirmation. Hooks allow to get to know which image the command was targeted.

Eventually, you might use two independent flags (bits) in GPREGRET as well for recognizing the state per-image and the common state.

Alternatively, if you know the sequence of loading images, then you can introduce a custom DFU state management image that you need. You can add a mcumgr custom command for driving the state.

Time out is something that you should consider as a precaution.

-Amanda H.

RE: MCUBoot BLE DFU fails due to custom power-on / accidental boot logic intercepting DFU reboots

Ben_M — Thu, 22 Jan 2026 09:52:01 GMT

Hi Amanda,

Thanks for the clarification — using GPREGRET / reset-retention registers to mark “DFU in progress” makes perfect sense, and I’ve implemented this approach to prevent my application from entering the accidental-boot sleep path during DFU reboots.

However, after implementing this, I ran into a follow-up question regarding where and when the GPREGRET flag should be set and cleared in the context of nRF5340 + MCUBoot + SMP OTA using nRF Connect for Mobile.

Context

Platform: nRF5340, NCS v2.9.0
OTA method: BLE SMP (mcumgr), uploading dfu_application.zip from nRF Connect Mobile
DFU requires multiple resets, and GPREGRET successfully allows bypassing the sleep logic across those resets.

Follow-up issue

In practice, I found the DFU process appears to involve multiple stages and resets by annotation boot logic code:

DFU progresses to ~60%, device resets
DFU continues to ~90%, device resets again
Sometimes progress restarts from 0%, and eventually reports “DFU success”

To support this, I currently set GPREGRET when DFU upload activity starts (e.g. on img_mgmt upload chunk callbacks), which works well to keep the device DFU-capable across resets.

The open question is about clearing the GPREGRET flag:

Clearing it based on boot_is_img_confirmed() can be too early, because DFU may still need additional resets or transfer stages.
Relying solely on image confirmation does not reliably indicate that the entire DFU session is complete, especially with multi-reset behavior on nRF5340.

Question

From Nordic’s perspective, what is the recommended best practice for:

Setting the GPREGRET “DFU in progress” flag
- Is setting it on the first img_mgmt upload chunk / DFU_STARTED event the intended approach?
Clearing the GPREGRET flag
- Is there a specific mcumgr/img_mgmt event (e.g. DFU_CONFIRMED, DFU_STOPPED) that should be treated as the authoritative “DFU session complete” signal when using nRF Connect Mobile?
- Or is an idle/timeout-based clearing strategy expected for SMP OTA sessions that span multiple resets?

The goal is to avoid both:

prematurely clearing the flag and interrupting DFU, and
leaving the flag set permanently and bypassing normal boot logic after DFU completes.

Any guidance on the intended lifecycle of a “DFU in progress” marker for nRF5340 SMP OTA would be greatly appreciated!

RE: MCUBoot BLE DFU fails due to custom power-on / accidental boot logic intercepting DFU reboots

Amanda Hsieh — Wed, 21 Jan 2026 16:50:52 GMT

Hi Ben,

[quote user=""]Is using GPREGRET / reset-retention registers the recommended approach to mark “DFU in progress” across reboots?[/quote]

Yes, you can use GPREGRET (or a similar reset-retention register) to mark “DFU in progress” before rebooting to instruct your application to enter the desired boot logic during DFU. Also see this post.

Regards,
Amanda H.