Cannot DFU flash unsigned/unencrypted firmware after flashing BT_SECURITY_L3 encrypted firmware on nRF52832

RE: Cannot DFU flash unsigned/unencrypted firmware after flashing BT_SECURITY_L3 encrypted firmware on nRF52832

Einar Thorsrud — Tue, 24 Mar 2026 14:23:51 GMT

Hi,

I see. The issue you are seeing now should not be related to the BLE link at all, rather it is clear that you have an image pending and are attempting to upload a new image. There are a couple of possible reasons for this:

Did you reset after uploading the new image? If not, MCUboot will do nothing, and the new image will still be in the secondary slot.
You selected "test" instead of "confirm", and the image was not confirmed either via SMP or by itself (calling boot_write_img_confirmed())

RE: Cannot DFU flash unsigned/unencrypted firmware after flashing BT_SECURITY_L3 encrypted firmware on nRF52832

Ferhat0 — Tue, 24 Mar 2026 10:24:39 GMT

Hi,

Thank you for the quick response and clarification.

Yes, you are exactly right. I do not mean firmware image encryption. I mean BLE link encryption. Specifically, I am using a static passkey defined in the code, so the phone must enter this static password to connect and pair with the device (BT_SECURITY_L3).

I tested your suggestion and added CONFIG_MCUMGR_TRANSPORT_BT_PERM_RW_AUTHEN=n to my prj.conf. This successfully allowed me to flash the "unencrypted" (no BLE security / passkey-less) firmware via DFU over the air.

However, a new issue occurred after this step: After successfully transitioning to the passkey-less firmware, when I try to flash the passkey-protected (BT_SECURITY_L3) firmware back onto the device via DFU, it gets stuck.

The behavior is as follows:

The DFU upload process completes (reaches 100%), but the device does not successfully boot into the new image.
The image gets stuck in the "pending" state.
When I check the slot info via the nRF Connect app, one of the slots shows the new image as pending.
If I try to flash the firmware again or send a confirm command, the app rejects it and gives an "SMP Command Error: Image operation already pending" error (indicating both slots are busy/full).

What causes the MCUboot state machine to get stuck in this "pending" state during this specific transition? Does the device fail to self-confirm the image upon reboot because of the sudden L3 security requirement, or is there another configuration I am missing to handle this consecutive DFU chain?

Thank you for your help.

RE: Cannot DFU flash unsigned/unencrypted firmware after flashing BT_SECURITY_L3 encrypted firmware on nRF52832

Einar Thorsrud — Fri, 20 Mar 2026 13:45:42 GMT

Hi,

I wonder if you can clarify what you mean by encrypted firmware in this context. Do you mean that the firmware image itself is encrypted (which is possible not not directly supported in nRF Connect SDK nor for nRF52 series devices)? Of rather that there are differences in the firmware when it comes to if it use BLE pairing/bonding (so encrypted BLE communication)? It seems to me like it is only the latter, but please clarify.

If you have CONFIG_MCUMGR_TRANSPORT_BT_PERM_RW_AUTHEN enabled, this means that the SMP service used for DFU will only work with pairing/bonding. If so, it will not be possible to perform an update without an encrypted link. This is normally sensible, but if you want to allows DFU ithout bonding that is absolutely possible. Then you need to explicitly set CONFIG_MCUMGR_TRANSPORT_BT_PERM_RW_AUTHEN=n in. your prj.conf, as this is enabled by default when you have SMP (pairing/bonding) enabled in. your build.