[McuMgr] Error : NOT_SUPPORTED during DFU by BLE with MCUBoot

[Julien]

Hi

I am currently to add DFU function on my custom device.

So I had McuBoot, and i would like to make the DFU by BLE.

I follow this link in order to do that https://github.com/hellesvik-nordic/samples_for_nrf_connect_sdk/tree/main/bootloader_samples/smp/mcuboot_smp_ble.

It's works well on my nrf5340dk, i also try to report the DFU on peripheral_lbs samples and still working.

But when i am trying to do the same thing on my custom board, i got this error [McuMgr] Error : NOT_SUPPORTED 

Fullscreen error_mcumgr.txt Download

nRF Connect, 2023-10-10
KRepgt (CE:71:DC:F2:77:E6)
V	08:47:42.977	[McuMgr] Connecting...
D	08:47:42.981	[McuMgr] gatt = device.connectGatt(autoConnect = false, TRANSPORT_LE, LE 1M)
D	08:47:43.015	[McuMgr] [Callback] Connection state changed with status: 0 and new state: 2 (CONNECTED)
I	08:47:43.020	[McuMgr] Connected to CE:71:DC:F2:77:E6
D	08:47:43.026	[McuMgr] wait(300)
I	08:47:43.031	[McuMgr] MTU changed to: 498
V	08:47:43.332	[McuMgr] Discovering services...
D	08:47:43.337	[McuMgr] gatt.discoverServices()
I	08:47:43.342	[McuMgr] Services discovered
V	08:47:43.346	[McuMgr] Primary service found
D	08:47:43.614	[McuMgr] gatt.setCharacteristicNotification(da2e7828-fbce-4e01-ae9e-261174997c48, true)
V	08:47:43.622	[McuMgr] Enabling notifications for da2e7828-fbce-4e01-ae9e-261174997c48
D	08:47:43.632	[McuMgr] descriptor.setValue(0x01-00)
D	08:47:43.642	[McuMgr] gatt.writeDescriptor(00002902-0000-1000-8000-00805f9b34fb)
I	08:47:43.853	[McuMgr] Data written to descr. 00002902-0000-1000-8000-00805f9b34fb
I	08:47:43.862	[McuMgr] Notifications enabled
V	08:47:43.869	[McuMgr] Waiting for value change...
V	08:47:43.877	[McuMgr] Writing characteristic da2e7828-fbce-4e01-ae9e-261174997c48 (WRITE COMMAND)
D	08:47:43.883	[McuMgr] characteristic.setValue(0x000000010000FF06A0)
D	08:47:43.890	[McuMgr] characteristic.setWriteType(WRITE COMMAND)
D	08:47:43.896	[McuMgr] gatt.writeCharacteristic(da2e7828-fbce-4e01-ae9e-261174997c48)
I	08:47:43.974	[McuMgr] Data written to da2e7828-fbce-4e01-ae9e-261174997c48
I	08:47:44.108	[McuMgr] Notification received from da2e7828-fbce-4e01-ae9e-261174997c48, value: (0x) 01-00-00-19-00-00-FF-06-BF-68-62-75-66-5F-73-69-7A-65-19-09-AB-69-62-75-66-5F-63-6F-75-6E-74-04-FF
I	08:47:44.116	[McuMgr] Wait for value changed complete
A	08:47:44.128	[McuMgr] Received Header (Op: 1, Flags: 0, Len: 25, Group: 0, Seq: 255, Command: 6) CBOR {"buf_size":2475,"buf_count":4}
I	08:47:44.140	[McuMgr] SMP reassembly supported with buffer size: 2475 bytes and count: 4
A	08:47:44.147	[McuMgr] Sending (10 bytes) Header (Op: 0, Flags: 0, Len: 2, Group: 1, Seq: 0, Command: 0) CBOR {}
V	08:47:44.150	[McuMgr] Writing characteristic da2e7828-fbce-4e01-ae9e-261174997c48 (WRITE COMMAND)
D	08:47:44.155	[McuMgr] characteristic.setValue(0x0000000200010000BFFF)
D	08:47:44.160	[McuMgr] characteristic.setWriteType(WRITE COMMAND)
D	08:47:44.165	[McuMgr] gatt.writeCharacteristic(da2e7828-fbce-4e01-ae9e-261174997c48)
I	08:47:44.172	[McuMgr] Data written to da2e7828-fbce-4e01-ae9e-261174997c48
I	08:47:44.322	Connection parameters updated (interval: 11.25ms, latency: 0, timeout: 420ms)
I	08:47:44.367	[McuMgr] Notification received from da2e7828-fbce-4e01-ae9e-261174997c48, value: (0x) 01-00-00-F4-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-65-30-2E-30-2E-30-64-68-61-73-68-58-20-B8-B3-9B-09-96-2F-8B-32-C2-EA-EE-F8-78-8E-0D-E3-2B-16-95-60-8A-F8-D1-F6-6E-6A-43-11-5B-BE-21-2A-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-BF-64-73-6C-6F-74-01-67-76-65-72-73-69-6F-6E-65-30-2E-30-2E-30-64-68-61-73-68-58-20-BC-1D-3D-F3-0F-1F-9B-C1-93-C2-59-CC-F4-86-D1-FD-75-31-F2-32-44-2B-AF-71-18-FE-4F-2D-34-44-0D-58-68-62-6F-6F-74-61-62-6C-65-F5-67-70-65-6E-64-69-6E-67-F5-69-63-6F-6E-66-69-72-6D-65-64-F4-66-61-63-74-69-76-65-F4-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
I	08:47:44.377	[McuMgr] Connection parameters updated (interval: 11.25ms, latency: 0, timeout: 420ms)
A	08:47:44.390	[McuMgr] Received Header (Op: 1, Flags: 0, Len: 244, Group: 1, Seq: 0, Command: 0) CBOR {"images":[{"slot":0,"version":"0.0.0","hash":"uLObCZYvizLC6u74eI4N4ysWlWCK+NH2bmpDEVu+ISo=","bootable":true,"pending":false,"confirmed":true,"active":true,"permanent":false},{"slot":1,"version":"0.0.0","hash":"vB098w8fm8GTwlnM9IbR/XUx8jJEK69xGP5PLTREDVg=","bootable":true,"pending":true,"confirmed":false,"active":false,"permanent":false}],"splitStatus":0}
V	08:47:44.433	[McuMgr] Uploading firmware...
A	08:47:44.445	[McuMgr] Sending (10 bytes) Header (Op: 2, Flags: 0, Len: 2, Group: 63, Seq: 1, Command: 0) CBOR {}
V	08:47:44.650	[McuMgr] Writing characteristic da2e7828-fbce-4e01-ae9e-261174997c48 (WRITE COMMAND)
D	08:47:44.657	[McuMgr] characteristic.setValue(0x02000002003F0100BFFF)
D	08:47:44.664	[McuMgr] characteristic.setWriteType(WRITE COMMAND)
D	08:47:44.670	[McuMgr] gatt.writeCharacteristic(da2e7828-fbce-4e01-ae9e-261174997c48)
I	08:47:44.695	[McuMgr] Data written to da2e7828-fbce-4e01-ae9e-261174997c48
I	08:47:44.704	[McuMgr] Notification received from da2e7828-fbce-4e01-ae9e-261174997c48, value: (0x) 03-00-00-06-00-3F-01-00-BF-62-72-63-08-FF
A	08:47:44.715	[McuMgr] Received Header (Op: 3, Flags: 0, Len: 6, Group: 63, Seq: 1, Command: 0) CBOR {"rc":8}
W	08:47:44.723	[McuMgr] Error: NOT_SUPPORTED (8)
V	08:47:44.737	[McuMgr] New state: CONFIRM
A	08:47:45.001	[McuMgr] Sending (58 bytes) Header (Op: 2, Flags: 0, Len: 50, Group: 1, Seq: 2, Command: 0) CBOR {"confirm":true,"hash":"vB098w8fm8GTwlnM9IbR/XUx8jJEK69xGP5PLTREDVg="}
V	08:47:45.012	[McuMgr] Writing characteristic da2e7828-fbce-4e01-ae9e-261174997c48 (WRITE COMMAND)
D	08:47:45.019	[McuMgr] characteristic.setValue(0x0200003200010200BF67636F6E6669726DF564686173685820BC1D3DF30F1F9BC193C259CCF486D1FD7531F232442BAF7118FE4F2D34440D58FF)
D	08:47:45.027	[McuMgr] characteristic.setWriteType(WRITE COMMAND)
D	08:47:45.034	[McuMgr] gatt.writeCharacteristic(da2e7828-fbce-4e01-ae9e-261174997c48)
I	08:47:45.058	[McuMgr] Data written to da2e7828-fbce-4e01-ae9e-261174997c48
I	08:47:45.239	[McuMgr] Notification received from da2e7828-fbce-4e01-ae9e-261174997c48, value: (0x) 03-00-00-F4-00-01-02-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-65-30-2E-30-2E-30-64-68-61-73-68-58-20-B8-B3-9B-09-96-2F-8B-32-C2-EA-EE-F8-78-8E-0D-E3-2B-16-95-60-8A-F8-D1-F6-6E-6A-43-11-5B-BE-21-2A-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-BF-64-73-6C-6F-74-01-67-76-65-72-73-69-6F-6E-65-30-2E-30-2E-30-64-68-61-73-68-58-20-BC-1D-3D-F3-0F-1F-9B-C1-93-C2-59-CC-F4-86-D1-FD-75-31-F2-32-44-2B-AF-71-18-FE-4F-2D-34-44-0D-58-68-62-6F-6F-74-61-62-6C-65-F5-67-70-65-6E-64-69-6E-67-F5-69-63-6F-6E-66-69-72-6D-65-64-F4-66-61-63-74-69-76-65-F4-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	08:47:45.252	[McuMgr] Received Header (Op: 3, Flags: 0, Len: 244, Group: 1, Seq: 2, Command: 0) CBOR {"images":[{"slot":0,"version":"0.0.0","hash":"uLObCZYvizLC6u74eI4N4ysWlWCK+NH2bmpDEVu+ISo=","bootable":true,"pending":false,"confirmed":true,"active":true,"permanent":false},{"slot":1,"version":"0.0.0","hash":"vB098w8fm8GTwlnM9IbR/XUx8jJEK69xGP5PLTREDVg=","bootable":true,"pending":true,"confirmed":false,"active":false,"permanent":false}],"splitStatus":0}
V	08:47:45.322	[McuMgr] Disconnecting...
D	08:47:45.330	[McuMgr] gatt.disconnect()
D	08:47:45.591	[McuMgr] [Callback] Connection state changed with status: 0 and new state: 0 (DISCONNECTED)
I	08:47:45.600	[McuMgr] Disconnected
D	08:47:45.609	[McuMgr] gatt.close()
I	08:47:50.201	Connection parameters updated (interval: 40.0ms, latency: 0, timeout: 420ms)
V	08:54:07.656	Disconnecting...
D	08:54:07.656	gatt.disconnect()
D	08:54:07.687	[Callback] Connection state changed with status: 0 and new state: DISCONNECTED (0)
I	08:54:07.687	Disconnected
D	08:54:08.702	[Broadcast] Action received: android.bluetooth.device.action.ACL_DISCONNECTED

See my prj.conf

# nothing here
CONFIG_RTT_CONSOLE=y

CONFIG_I2C=y
CONFIG_GPIO=y

CONFIG_NEWLIB_LIBC=y

# BLE definition 
CONFIG_BT=y
CONFIG_BT_CENTRAL=y
CONFIG_BT_GATT_CLIENT=y
CONFIG_BT_GATT_DM=y

CONFIG_BT_PERIPHERAL=y
CONFIG_BT_MAX_CONN=1
CONFIG_BT_L2CAP_TX_BUF_COUNT=5
CONFIG_BT_DEVICE_NAME="KRepet"
CONFIG_BT_DEVICE_APPEARANCE=962

CONFIG_HEAP_MEM_POOL_SIZE=2048

CONFIG_BT_SCAN=y
CONFIG_BT_SCAN_UUID_CNT=8

CONFIG_MPSL=y
CONFIG_MPSL_FEM=y
CONFIG_MPSL_FEM_SIMPLE_GPIO=y

# Ensure an MCUboot-compatible binary is generated.
CONFIG_BOOTLOADER_MCUBOOT=y

CONFIG_SECURE_BOOT=n

# Enable SMP Server
CONFIG_MCUMGR=y
CONFIG_MCUMGR_GRP_IMG=y

# CONFIG_MCUMGR_GRP_IMG dependencies
CONFIG_FLASH=y
CONFIG_IMG_MANAGER=y

# CONFIG_IMG_MANAGER dependencies
CONFIG_STREAM_FLASH=y

# CONFIG_MCUMGR dependencies
CONFIG_NET_BUF=y
CONFIG_ZCBOR=y

# Required for CONFIG_IMG_MANAGER
CONFIG_FLASH_MAP=y

# Enable BLE transfer
CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU=y

CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU_SPEEDUP=y

CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=4096

I am not using an external flash to do the DFU.

My environment are

-IDE : Visual Studio Code

-Zephyr: V2.4.1

-OS: Windows

-custom Board: nrf52833

Thanks,

Best Regards,

Julien

[AHaug]

Hi Julien,

A couple of questions here to start with as an attempt to narrow down what could be wrong

1. In your previous case you mention that you're testing with a nRF5340DK. Have you at any point tested and verified that you're able to add DFU support to a non-custom nRF52 based board such as the nRF52840DK?
2. You're mentioning 'Zephyr v2.4.1'. Could you clarify if you're referring to 'nRF Connect SDK v2.4.1' or if you're actually using a pure Zephyr environment? 
3. Are you able to compile, flash and run any other non-DFU based samples from the SDK to your custom board?
4. Do you get any warnings when compiling?
5. Are you able to add DFU to your custom board using other transports than BLE? For instance using the UART sample instead? github.com/.../mcuboot_smp_uart

Kind regards,
Andreas

[Julien]

Hi AHaug,

1. Currently my only board are nrf5340, i could test on other board tomorrow

2. Apologize, it is nRF Connect SDK v2.4.1

3. I have not try, but i'm able to communicate with i2c, enable bluetooth and connect to it or connect to other device

4. No warning

5. I have no uart available on my custom board

What meaning the error code 8 on McuMgr?

Regards,

[AHaug]

Yep, I agree they do.

Can you share a minimal version of your project (zip and upload it) that has this issue? Remember that this is a public ticket so don't upload any sensitive information/code that is confidential

Kind regards,
Andreas

[Julien]

Hi Ahaug

Los of twists on my side.

I start to prepare a minimal version of my project and when i want to send it to you i observe that DFU over SMP service worked, and if you test with the whole project, it still does not work.

My guess is issue come from size of my firmware.

Size are at the limit

 

Memory region         Used Size  Region Size  %age Used
           FLASH:      231196 B     237056 B     97.53%
             RAM:       63068 B       128 KB     48.12%
        IDT_LIST:          0 GB         2 KB      0.00%

and should provoke an issue with mcuboot.

Once i tried a DFU with the .zip where the dfu not working, every other zip file will not work, even those that worked before.

Best Regards,

Julien

[Julien]

I place the app_moved_test_update.hex app_moved_test_update.hex on nrf connect, it show me that my memory is overflowed.

---EDIT----

I notice that all app_moved_test_update.hex reach address 0x7FFFF on nrf connect

--------------

Regards,

Julien

[Julien]

I test with the SMP sample, after i tried with this zip file 6012.dfu_application.zip, no other DFU works

Regards

Julien

[AHaug]

Hi,

I was completely locked in on that this was a "custom board issue" and had the 5340 from your previous case fresh in my mind so a ROM issue was not on my mind at all!..  The nRF52833 has half the available flash than the nRF5340 has, so as you describe this is a ROM issue due to a too large application, which makes perfect sense regarding why you're not able to perform the update

Your firmware is 237KB and from the partition manager report you have 232kB available in the primary application slot and 231kB in the secondary application slots.  It's just a bit weird that you were able to flash the firmware and run it since it's larger than what the partition manager reports without any warnings or errors

The primary and secondary application slot needs to be of the same size of the original image as this is where the update image will be stored before you perform the swap upgrade. In this case if you create a 232kB app, you will not be able to fit the upgrade image to the secondary slot in case you create a 232kB update.

I will also add this resource regarding the partition manager and how to add a static partition (which may be very useful to have if you intend to have multiple update cycles): https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/scripts/partition_manager/partition_manager.html#static-configuration

Optimizing your firmware w.r.t. ROM, adding an external flash and moving the secondary application slot to the external flash or reducing the size of MCUboot by optimizing it will most likely solve the issue with the Custom board + your custom firmware

Kind regards,
Andreas

[Julien]

Hi Ahaug,

In fact, my firmware is 231196 B if i believe in VSC.

As you say "you have 232kB available in the primary application slot and 231kB in the secondary application slots", so it's normal that i'm able to perform a flash on a primary slot.

But when you want to make a DFU there is no enough size on secondary slot.

And after that, mcuboot seem to be broke, because i cannot realize any other dfu. 

My issue seems to come from a different size between primary and secondary slot and then a bad managing of mcuboot who block any other dfu 

Best regards

Julien

[AHaug]

Julien said:

In fact, my firmware is 231196 B if i believe in VSC.

Yep, I read the wrong column. 237056B is what you have available on that region, 231196 is your firmware.

Julien said:

My issue seems to come from a different size between primary and secondary slot and then a bad managing of mcuboot who block any other dfu 

Are you able to resolve that issue by using a static partitioning map, setting both the primary and secondary application to be larger than your application? Remember to leave some room for necessary for headers, MCUboot and such. You can have a look at the machine learning algorithm for a couple of tips to optimize MCUboot https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/applications/machine_learning/README.html

General ROM and RAM optimization tips can be seen here developer.nordicsemi.com/.../index.html

Kind regards,
Andreas

[Julien]

Hi 

YEEES ! it is working with my pm_static.yml.

Last thing, i don't understand it's why only 231kB in the secondary application slots, if i refer from 

  flash_primary (0x80000 - 512kB):
+-------------------------------------------------+
| 0x0: mcuboot (0xc000 - 48kB)                    |
+---0xc000: mcuboot_primary (0x3a000 - 232kB)-----+
| 0xc000: mcuboot_pad (0x200 - 512B)              |
+---0xc200: mcuboot_primary_app (0x39e00 - 231kB)-+
| 0xc200: app (0x39e00 - 231kB)                   |
+-------------------------------------------------+
| 0x46000: mcuboot_secondary (0x3a000 - 232kB)    |
+-------------------------------------------------+

  sram_primary (0x20000 - 128kB):
+--------------------------------------------+
| 0x20000000: sram_primary (0x20000 - 128kB) |
+--------------------------------------------+

We read 232kb on mcuboot secondary. I assume that it come from scratch_partition  but not mentionned on partition_manager_report

Regard,

Julien

[AHaug]

Thats great!

Julien said:

Last thing, i don't understand it's why only 231kB in the secondary application slots, if i refer from 

Basically it is due to how the partition manager has defined the partitions and paddings. You're using all of the 512kB you have available, but the report only showcases that you're using 511,5kB (even though it should use the full space), i.e 48kB + 232kB + 512B + 231kB instead of 48kB + 232kB + 512B + 231,5kB

Could you also post your pm_static for the successfull build? I will have a closer look at this after the weekend

Kind regards,
Andreas

[Julien]

All right seem logical

app:
  address: 0xa200
  end_address: 0x45000
  region: flash_primary
  size: 0x3ae00
mcuboot:
  address: 0x0
  end_address: 0xa000
  placement:
    before:
    - mcuboot_primary
  region: flash_primary
  size: 0xa000
mcuboot_pad:
  address: 0xa000
  end_address: 0xa200
  placement:
    align:
      start: 0x1000
    before:
    - mcuboot_primary_app
  region: flash_primary
  size: 0x200
mcuboot_primary:
  address: 0xa000
  end_address: 0x45000
  orig_span: &id001
  - mcuboot_pad
  - app
  region: flash_primary
  sharers: 0x1
  size: 0x3b000
  span: *id001
mcuboot_primary_app:
  address: 0xa200
  end_address: 0x45000
  orig_span: &id002
  - app
  region: flash_primary
  size: 0x3ae00
  span: *id002
mcuboot_secondary:
  address: 0x45000
  end_address: 0x80000
  placement:
    after:
    - mcuboot_primary
    align:
      start: 0x1000
    align_next: 0x1000
  region: flash_primary
  share_size:
  - mcuboot_primary
  size: 0x3b000
sram_primary:
  address: 0x20000000
  end_address: 0x20020000
  region: sram_primary
  size: 0x20000

See my pm_static, it was just for tested actually, i will work on design it smartly in a next step.

Best regards,

Julien