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

[Ben_M]

Hi Nordic Team,

I am using MCUBoot with BLE DFU on nRF5340 and I am facing an issue where the DFU process cannot complete due to my application’s custom boot logic.

After chipset power-on, my application determines the boot mode based on the power-on reason and button state:

1. Accidental / short press power-on
   → The device immediately enters deep sleep to avoid unintended wake-up.

2. Button long-press
   → Normal application startup.

3. Charger insertion detected
   → Enter charging-only mode.

This logic works well for normal usage, but it conflicts with DFU.

Problem

During MCUBoot BLE DFU, I found the device needs to reboot multiple times without the above boot logic .
However, after each reboot, my application treats the reset as a normal power-on event and re-enters the “accidental boot → sleep” path.

As a result:

• The DFU process is interrupted.

• The new image cannot be confirmed.

• DFU may loop indefinitely or fail completely.

In short, DFU-triggered reboots are incorrectly handled as user power-on events by the application logic.

Question

What is the recommended way on Nordic platforms to distinguish DFU-related reboots from normal power-on / user-triggered boots, so that the application does not enter sleep or charging-only mode during DFU? Is using GPREGRET / reset-retention registers the recommended approach to mark “DFU in progress” across reboots?

Any guidance or reference designs would be greatly appreciated.

Best Regards!

Ben

[Amanda Hsieh]

Hi Ben, 

Is using GPREGRET / reset-retention registers the recommended approach to mark “DFU in progress” across reboots?

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.

[Ben_M]

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:

1. Setting the GPREGRET “DFU in progress” flag

   • Is setting it on the first img_mgmt upload chunk / DFU_STARTED event the intended approach?

2. 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!

[Amanda Hsieh]

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.