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

[Ferhat0]

Hello,
I am working on a project using nRF52832 with Zephyr RTOS (NCS v2.7.0) and MCUboot. I have implemented BLE passkey-based security (BT_SECURITY_L3) on the device. I use BLE security level: BT_SECURITY_L3 (authenticated pairing with encryption, passkey entry)
The behavior I observe:
1. Device has unencrypted (no BLE security) firmware flashed via J-Link → works fine
2. I flash encrypted (BT_SECURITY_L3) firmware via DFU over BLE → succeeds
3. I flash another encrypted firmware on top via DFU → succeeds
4. I try to flash unencrypted (no BLE security) firmware via DFU → FAILS, DFU is rejected
My question: Is this behavior caused by BT_SECURITY_L3 blocking the DFU transport because the unencrypted firmware DFU package is sent without pairing? Or is this related to MCUboot downgrade protection rejecting the lower version image? If it is the security level blocking the DFU, is CONFIG_MCUMGR_TRANSPORT_BT_PERM_RW_AUTHEN the relevant config here? And if so, is there a recommended way to allow flashing an unencrypted firmware via DFU while still keeping BT_SECURITY_L3 for normal BLE communication?
Any guidance would be appreciated.
Thank you.

[Einar Thorsrud]

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.

[Ferhat0]

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:

1. The DFU upload process completes (reaches 100%), but the device does not successfully boot into the new image.

2. The image gets stuck in the "pending" state.

3. When I check the slot info via the nRF Connect app, one of the slots shows the new image as pending.

4. 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.

[Einar Thorsrud]

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:

1. 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.
2. You selected "test" instead of "confirm", and the image was not confirmed either via SMP or by itself (calling boot_write_img_confirmed())