DFU of MCUBoot over BLE fails with NOT_SUPPORTED

[Rokk Research]

Hi, I'm using NCS v1.9.1, and attempting to upgrade MCUBoot via DFU over BLE using the nRF Connect for Mobile app.

I'm able to successfully DFU the application image.  However, after many attempts using different configuration options for B0, MCUBoot, and the application image, I'm still unable to DFU MCUBoot to either slot.

I have these configs enabled in my application image in prj.conf:

CONFIG_SECURE_BOOT=y
CONFIG_SB_SIGNING_KEY_FILE="/var/tmp/mcuboot_priv.pem"
CONFIG_BOOTLOADER_MCUBOOT=y
CONFIG_MCUBOOT_IMAGE_VERSION="0.1.3+3"
CONFIG_MCUMGR=y
CONFIG_MCUMGR_CMD_OS_MGMT=y
CONFIG_MCUMGR_CMD_IMG_MGMT=y
CONFIG_MCUMGR_SMP_BT=y
CONFIG_MCUMGR_SMP_BT_AUTHEN=n
CONFIG_FW_INFO_FIRMWARE_VERSION=7
CONFIG_BUILD_S1_VARIANT=y

And this is the MCUBoot config (defined in child_image/mcuboot.conf):

CONFIG_FW_INFO_FIRMWARE_VERSION=10

CONFIG_MCUBOOT_IMAGE_VERSION="0.1.2+3"

CONFIG_BOOT_SIGNATURE_KEY_FILE="/var/tmp/mcuboot_priv.pem"

I bumped the firmware version, rebuilt, and attempted to DFU MCUBoot - here are the logs from nRF Connect for Mobile when I attempt to DFU the dfu_mcuboot.zip file found in build/zephyr:

nRF Connect, 2022-11-15
Device_Bringup (F8:8E:E5:F9:5E:80)
V 10:31:39.786 Connecting to F8:8E:E5:F9:5E:80...
D 10:31:39.786 gatt = device.connectGatt(autoConnect = false, TRANSPORT_LE, preferred PHY = LE 1M)
D 10:31:40.032 [Callback] Connection state changed with status: 0 and new state: CONNECTED (2)
I 10:31:40.032 Connected to F8:8E:E5:F9:5E:80
V 10:31:40.050 Discovering services...
D 10:31:40.050 gatt.discoverServices()
D 10:31:40.059 [Broadcast] Action received: android.bluetooth.device.action.ACL_CONNECTED
I 10:31:40.473 Connection parameters updated (interval: 7.5ms, latency: 0, timeout: 5000ms)
D 10:31:40.780 [Callback] Services discovered with status: 0
I 10:31:40.780 Services discovered
V 10:31:40.785 Generic Attribute (0x1801)
- Service Changed [I] (0x2A05)
Client Characteristic Configuration (0x2902)
- Client Supported Features [R W] (0x2B29)
- Database Hash [R] (0x2B2A)
Generic Access (0x1800)
- Device Name [R] (0x2A00)
- Appearance [R] (0x2A01)
- Peripheral Preferred Connection Parameters [R] (0x2A04)
Nordic UART Service (6e400001-b5a3-f393-e0a9-e50e24dcca9e)
- TX Characteristic [N] (6e400003-b5a3-f393-e0a9-e50e24dcca9e)
Client Characteristic Configuration (0x2902)
- RX Characteristic [W WNR] (6e400002-b5a3-f393-e0a9-e50e24dcca9e)
SMP Service (8d53dc1d-1db7-4cd3-868b-8a527460aa84)
- SMP Characteristic [N WNR] (da2e7828-fbce-4e01-ae9e-261174997c48)
Client Characteristic Configuration (0x2902)
D 10:31:40.785 gatt.setCharacteristicNotification(00002a05-0000-1000-8000-00805f9b34fb, true)
D 10:31:40.786 gatt.setCharacteristicNotification(6e400003-b5a3-f393-e0a9-e50e24dcca9e, true)
I 10:31:40.868 Connection parameters updated (interval: 45.0ms, latency: 0, timeout: 5000ms)
I 10:31:45.279 Connection parameters updated (interval: 45.0ms, latency: 0, timeout: 420ms)
V 10:32:00.617 [McuMgr] Connecting...
D 10:32:00.620 [McuMgr] gatt = device.connectGatt(autoConnect = false, TRANSPORT_LE, LE 1M)
D 10:32:00.656 [McuMgr] [Callback] Connection state changed with status: 0 and new state: 2 (CONNECTED)
I 10:32:00.659 [McuMgr] Connected to F8:8E:E5:F9:5E:80
D 10:32:00.660 [McuMgr] wait(300)
V 10:32:00.963 [McuMgr] Discovering services...
D 10:32:00.966 [McuMgr] gatt.discoverServices()
I 10:32:00.977 [McuMgr] Services discovered
V 10:32:00.981 [McuMgr] Primary service found
V 10:32:00.989 [McuMgr] Requesting new MTU...
D 10:32:00.991 [McuMgr] gatt.requestMtu(498)
I 10:32:01.077 [McuMgr] MTU changed to: 252
D 10:32:01.081 [McuMgr] gatt.setCharacteristicNotification(da2e7828-fbce-4e01-ae9e-261174997c48, true)
V 10:32:01.086 [McuMgr] Enabling notifications for da2e7828-fbce-4e01-ae9e-261174997c48
D 10:32:01.088 [McuMgr] gatt.writeDescriptor(00002902-0000-1000-8000-00805f9b34fb, value=0x01-00)
I 10:32:01.257 [McuMgr] Data written to descr. 00002902-0000-1000-8000-00805f9b34fb, value: (0x) 01-00
I 10:32:01.262 [McuMgr] Notifications enabled
V 10:32:01.264 [McuMgr] Writing characteristic da2e7828-fbce-4e01-ae9e-261174997c48 (WRITE COMMAND)
D 10:32:01.267 [McuMgr] gatt.writeCharacteristic(da2e7828-fbce-4e01-ae9e-261174997c48)
I 10:32:01.277 [McuMgr] Data written to da2e7828-fbce-4e01-ae9e-261174997c48, value: (0x) 00-00-00-01-00-00-FF-06-A0
I 10:32:01.391 [McuMgr] Notification received from da2e7828-fbce-4e01-ae9e-261174997c48, value: (0x) 01-00-00-06-00-00-FF-06-BF-62-72-63-08-FF
A 10:32:01.402 [McuMgr] Received Header (Op: 1, Flags: 0, Len: 6, Group: 0, Seq: 255, Command: 6) CBOR {"rc":8}
W 10:32:01.405 [McuMgr] Error: NOT_SUPPORTED (8)
A 10:32:01.419 [McuMgr] Sending (10 bytes) Header (Op: 0, Flags: 0, Len: 2, Group: 1, Seq: 0, Command: 0) CBOR {}
V 10:32:01.422 [McuMgr] Writing characteristic da2e7828-fbce-4e01-ae9e-261174997c48 (WRITE COMMAND)
D 10:32:01.423 [McuMgr] gatt.writeCharacteristic(da2e7828-fbce-4e01-ae9e-261174997c48)
I 10:32:01.426 [McuMgr] Data written to da2e7828-fbce-4e01-ae9e-261174997c48, value: (0x) 00-00-00-02-00-01-00-00-BF-FF
I 10:32:01.754 [McuMgr] Notification received from da2e7828-fbce-4e01-ae9e-261174997c48, value: (0x) 01-00-00-88-00-01-00-00-BF-66-69-6D-61-67-65-73-9F-BF-64-73-6C-6F-74-00-67-76-65-72-73-69-6F-6E-67-30-2E-31-2E-33-2E-33-64-68-61-73-68-58-20-EE-1D-7B-A1-5F-C2-90-C0-6F-3E-35-18-A4-16-6C-F0-6A-C4-57-03-35-2D-D1-F0-9B-A1-15-A3-C9-79-E7-8D-68-62-6F-6F-74-61-62-6C-65-F5-67-70-65-6E-64-69-6E-67-F4-69-63-6F-6E-66-69-72-6D-65-64-F5-66-61-63-74-69-76-65-F5-69-70-65-72-6D-61-6E-65-6E-74-F4-FF-FF-6B-73-70-6C-69-74-53-74-61-74-75-73-00-FF
A 10:32:01.770 [McuMgr] Received Header (Op: 1, Flags: 0, Len: 136, Group: 1, Seq: 0, Command: 0) CBOR {"images":[{"slot":0,"version":"0.1.3.3","hash":"7h17oV/CkMBvPjUYpBZs8GrEVwM1LdHwm6EVo8l5540=","bootable":true,"pending":false,"confirmed":true,"active":true,"permanent":false}],"splitStatus":0}
V 10:32:01.816 [McuMgr] Uploading firmware...
A 10:32:27.270 [McuMgr] 40015 bytes sent in 24794 ms (1.61 kB/s)
A 10:32:52.423 [McuMgr] 40016 bytes sent in 24524 ms (1.63 kB/s)
A 10:32:52.456 [McuMgr] Sending (10 bytes) Header (Op: 2, Flags: 0, Len: 2, Group: 63, Seq: 105, Command: 0) CBOR {}
V 10:32:52.461 [McuMgr] Writing characteristic da2e7828-fbce-4e01-ae9e-261174997c48 (WRITE COMMAND)
D 10:32:52.464 [McuMgr] gatt.writeCharacteristic(da2e7828-fbce-4e01-ae9e-261174997c48)
I 10:32:52.469 [McuMgr] Data written to da2e7828-fbce-4e01-ae9e-261174997c48, value: (0x) 02-00-00-02-00-3F-69-00-BF-FF
I 10:32:52.603 [McuMgr] Notification received from da2e7828-fbce-4e01-ae9e-261174997c48, value: (0x) 03-00-00-06-00-3F-69-00-BF-62-72-63-08-FF
A 10:32:52.607 [McuMgr] Received Header (Op: 3, Flags: 0, Len: 6, Group: 63, Seq: 105, Command: 0) CBOR {"rc":8}
W 10:32:52.618 [McuMgr] Error: NOT_SUPPORTED (8)
V 10:32:52.623 [McuMgr] New state: TEST
A 10:32:52.627 [McuMgr] Sending (58 bytes) Header (Op: 2, Flags: 0, Len: 50, Group: 1, Seq: 106, Command: 0) CBOR {"confirm":false,"hash":"xhwt/XiW5zEsJ42ZLiN0w+Myr3dL9xf+lq2Q7zcUQWs="}
V 10:32:52.631 [McuMgr] Writing characteristic da2e7828-fbce-4e01-ae9e-261174997c48 (WRITE COMMAND)
D 10:32:52.631 [McuMgr] gatt.writeCharacteristic(da2e7828-fbce-4e01-ae9e-261174997c48)
I 10:32:52.639 [McuMgr] Data written to da2e7828-fbce-4e01-ae9e-261174997c48, value: (0x) 02-00-00-32-00-01-6A-00-BF-67-63-6F-6E-66-69-72-6D-F4-64-68-61-73-68-58-20-C6-1C-2D-FD-78-96-E7-31-2C-27-8D-99-2E-23-74-C3-E3-32-AF-77-4B-F7-17-FE-96-AD-90-EF-37-14-41-6B-FF
I 10:32:53.100 [McuMgr] Notification received from da2e7828-fbce-4e01-ae9e-261174997c48, value: (0x) 03-00-00-06-00-01-6A-00-BF-62-72-63-03-FF
A 10:32:53.106 [McuMgr] Received Header (Op: 3, Flags: 0, Len: 6, Group: 1, Seq: 106, Command: 0) CBOR {"rc":3}
W 10:32:53.110 [McuMgr] Error: IN_VALUE (3)
V 10:32:53.127 [McuMgr] Disconnecting...
D 10:32:53.131 [McuMgr] gatt.disconnect()
D 10:32:53.159 [McuMgr] [Callback] Connection state changed with status: 0 and new state: 0 (DISCONNECTED)
I 10:32:53.164 [McuMgr] Disconnected
D 10:32:53.168 [McuMgr] gatt.close()

Any ideas what the issue could be or other things to try?  Thanks in advance.

[Hung Bui]

Hi Mike, 

I'm not so sure by having different CONFIG_FW_INFO_FIRMWARE_VERSION in proj.conf of the application and the mcuboot.conf of the MCUBoot would make it work. 

Have you tried to simply make the first build with CONFIG_FW_INFO_FIRMWARE_VERSION in mcuboot.conf = 1 for example. 
And then flash this in to the chip. 

In the nest step you change the CONFIG_FW_INFO_FIRMWARE_VERSION in mcuboot.conf to 2 and use the dfu_mcuboot.zip file of this new build to do DFU. 

[Rokk Research]

Thanks for the suggestion Hung - I removed CONFIG_FW_INFO_FIRMWARE_VERSION from prj.conf, and tried your suggestion of setting CONFIG_FW_INFO_FIRMWARE_VERSION=1 in mcuboot.conf, flashing that version, then trying to DFU the dfu_mcuboot.zip built with CONFIG_FW_INFO_FIRMWARE_VERSION=2 in mcuboot.conf.  I encountered the same results as before.

Is there a sample project that is known to support DFU of MCUBoot?  I've read thru the documentation and found the bootloader project, but that seems to be configured to build B0, and not necessarily demonstrate a DFU of MCUBoot.

[Hung Bui]

Hi Mike, 
I attached here a sample that worked (mostly) for me. I don't think it has any difference from yours. 
I modified peripheral_hr so that it has B0 and MCUBoot. 
The key file is provided and should be copied to a location, similar to your key file. 

peripheral_hr_smp_b0.zip

I can test by increase the CONFIG_FW_INFO_FIRMWARE_VERSION inside mcuboot.conf  and then rebuild pristine. And can see that I can FOTA update the new image and can see new version for example here is when it run on Slot 1 and version is 9.

Note that it's suggested to use Device Manager app to do FOTA instead of nRF Connect app on the phone. 

What I found out is that the dfu_mcuboot.zip currently doesn't work with the Device Manager App. 

You need to use the bin files, either signed_by_mcuboot_and_b0_s0_image_update.bin or signed_by_mcuboot_and_b0_s1_image_update.bin

First you may want to check which slot is active, for example if slot 0 is active (attempting to boot slot 0) then you need to update b0_s1 image. And if slot 1 is active you would need to update b0_s0 image. I only tested with "Confirm only". 

After you send the image you would need to reset the board once to be able for the MCUBoot to be replaced. You can either reset with pin reset or use the Advance mode on Device Manager App to reset. If you use Advance mode to upload, you need to do confirm manually. 

After that you should see the active slot is swapped and the version is updated. 

I'm still seeing an issue here is that if you do it wrongly (update wrong slot) it's not possible to correct it with a new image. For some reason MCUBoot refuse to accept new image. 

[Rokk Research]

Thank you Hung!  I followed your procedure and tried to DFU MCUBoot with your test app on our HW, and I still wasn't able to get it to work (it failed in the same way as before).

However, I then tried in on an nRF52 DK - and low and behold, I was able to reproduce your results!  I was able to update Slot 1, manually reboot, and observe it was booting into the new bootloader sent over DFU.

So it's great to know it's possible to get this to work despite some kinks with the lack of support for the .zip, targeting the correct slot, and requiring a manual reboot.  Our HW has a slightly different device tree than the DK and needs some seemingly unrelated changes to the configs, but clearly there is some difference (either config or DT) that is causing the MCUBoot DFU failure on our HW which I will work on figuring out.

Clearly having to know which slot needs to be updated could be problematic but perhaps the app could query which slot is currently active before sending the update.  And, bricking the device by sending the update to the wrong slot sounds like a serious bug.  But maybe these issues are addressed in a more recent version of the SDK?

In any case thanks again for the assistance!