DFU FOTA issue on NRF 52833 with NRF Connect Error [McuMgr] ERROR: NOT_SUPPORTED(8)

[Cloudscraper]

NRFConnect does not allow us to flash new firmware OTA under certain conditions.

Going into better details, we are developing some firmware on the NRF 52833 and a required functionality is to be able to update the firmware using DFU FOTA.

I have scouted the forums a lot and I have the feeling our issue is due to firmware total size (app_update.bin), which in our current state is 188kB.

This is the corresponding prj.conf

CONFIG_SOC_SERIES_NRF52X=y
CONFIG_SOC_NRF52833_QIAA=y
CONFIG_NFCT_PINS_AS_GPIOS=y
CONFIG_USE_SEGGER_RTT=y
CONFIG_RTT_CONSOLE=y
CONFIG_NRFX_USBD=y
CONFIG_UART_CONSOLE=n
CONFIG_USB_DEVICE_STACK=y
CONFIG_I2C=y
CONFIG_CBPRINTF_FP_SUPPORT=y #Enable floating point format specifiers
CONFIG_ADC=y
CONFIG_SPI=y
CONFIG_NRFX_SPIM2=y
CONFIG_SOC_NRF52832_ALLOW_SPIM_DESPITE_PAN_58=y
CONFIG_PWM=y
CONFIG_LED=y
CONFIG_LED_PWM=y
CONFIG_PM=y
CONFIG_PM_DEVICE=y
CONFIG_GPIO=y

CONFIG_NUM_PREEMPT_PRIORITIES=0
CONFIG_NUM_COOP_PRIORITIES=3
CONFIG_SYSTEM_WORKQUEUE_NO_YIELD=y

CONFIG_BOOTLOADER_MCUBOOT=y
CONFIG_IMG_MANAGER=y
CONFIG_MCUBOOT_IMG_MANAGER=y

CONFIG_BT=y
CONFIG_BT_HCI=y
CONFIG_BT_CTLR=y
CONFIG_BT_LL_SW_SPLIT=y
CONFIG_BT_DEVICE_NAME="MRA"
CONFIG_BT_PERIPHERAL=y

CONFIG_ADC=y
CONFIG_ADC_ASYNC=y

CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=2048

# Enable mcumgr.
CONFIG_MCUMGR=y

# Enable most core commands.
CONFIG_MCUMGR_CMD_IMG_MGMT=y
CONFIG_MCUMGR_CMD_OS_MGMT=y

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

# Allow for large Bluetooth data packets.
CONFIG_BT_L2CAP_TX_MTU=252
CONFIG_BT_BUF_ACL_RX_SIZE=256

# Enable the Bluetooth (unauthenticated) and shell mcumgr transports.
CONFIG_MCUMGR_SMP_BT=y
CONFIG_MCUMGR_SMP_BT_AUTHEN=n

# Some command handlers require a large stack.
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=4096

CONFIG_MCUBOOT_UTIL_LOG_LEVEL_DBG=y


# watchdog timer
CONFIG_WDT_LOG_LEVEL_DBG=y
CONFIG_WATCHDOG=y
CONFIG_WDT_DISABLE_AT_BOOT=n

#FLASH access
CONFIG_FLASH=y
CONFIG_FLASH_PAGE_LAYOUT=y
CONFIG_MPU_ALLOW_FLASH_WRITE=y


CONFIG_BT_DEVICE_APPEARANCE=965      


CONFIG_BT_MAX_CONN=1
CONFIG_BT_MAX_PAIRED=1
CONFIG_BT_SMP=y                                         
CONFIG_BT_L2CAP_TX_BUF_COUNT=5

CONFIG_BT_SETTINGS=y
CONFIG_FLASH_MAP=y
CONFIG_NVS=y
CONFIG_SETTINGS=y

CONFIG_BT_SMP_APP_PAIRING_ACCEPT=y

CONFIG_BT_FILTER_ACCEPT_LIST=y
CONFIG_BT_PRIVACY=y       
CONFIG_BT_BONDABLE=y       


CONFIG_BT_KEYS_OVERWRITE_OLDEST=y    

CONFIG_BT_CTLR_PRIVACY=y    
CONFIG_HEAP_MEM_POOL_SIZE=2048

CONFIG_BT_SMP_SC_PAIR_ONLY=n

This is the NRF Connect log whenever the DFU FOTA fails:

nRF Connect, 2025-01-21
Nordic_LBS (E9:28:DD:B4:12:7B)
V 10:08:32.204 [McuMgr] Connecting...
D 10:08:32.210 [McuMgr] gatt = device.connectGatt(autoConnect = false, TRANSPORT_LE, LE 1M)
D 10:08:32.288 [McuMgr] [Callback] Connection state changed with status: 0 and new state: 2 (CONNECTED)
I 10:08:32.292 [McuMgr] Connected to E9:28:DD:B4:12:7B
D 10:08:32.295 [McuMgr] wait(300)
I 10:08:32.298 [McuMgr] MTU changed to: 252
V 10:08:32.600 [McuMgr] Discovering services...
D 10:08:32.613 [McuMgr] gatt.discoverServices()
I 10:08:32.628 [McuMgr] Services discovered
V 10:08:32.634 [McuMgr] Primary service found
V 10:08:32.639 [McuMgr] Requesting new MTU...
D 10:08:32.642 [McuMgr] gatt.requestMtu(498)
I 10:08:32.691 [McuMgr] MTU changed to: 252
D 10:08:32.695 [McuMgr] gatt.setCharacteristicNotification(da2e7828-fbce-4e01-ae9e-261174997c48, true)
V 10:08:32.699 [McuMgr] Enabling notifications for da2e7828-fbce-4e01-ae9e-261174997c48
D 10:08:32.702 [McuMgr] descriptor.setValue(0x01-00)
D 10:08:32.705 [McuMgr] gatt.writeDescriptor(00002902-0000-1000-8000-00805f9b34fb)
I 10:08:32.797 [McuMgr] Data written to descr. 00002902-0000-1000-8000-00805f9b34fb
I 10:08:32.808 [McuMgr] Notifications enabled
V 10:08:32.811 [McuMgr] Waiting for value change...
V 10:08:32.814 [McuMgr] Writing characteristic da2e7828-fbce-4e01-ae9e-261174997c48 (WRITE COMMAND)
D 10:08:32.816 [McuMgr] characteristic.setValue(0x000000010000FF06A0)
D 10:08:32.819 [McuMgr] characteristic.setWriteType(WRITE COMMAND)
D 10:08:32.822 [McuMgr] gatt.writeCharacteristic(da2e7828-fbce-4e01-ae9e-261174997c48)
I 10:08:32.841 [McuMgr] Data written to da2e7828-fbce-4e01-ae9e-261174997c48
I 10:08:32.874 [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
I 10:08:32.878 [McuMgr] Wait for value changed complete
A 10:08:32.886 [McuMgr] Received Header (Version: 0, Op: 1, Flags: 0, Len: 6, Group: 0, Seq: 255, Command: 6) CBOR {"rc":8}
W 10:08:32.889 [McuMgr] Error: NOT_SUPPORTED (8)
V 10:08:32.893 [McuMgr] Requesting connection priority: HIGH (11.25–15ms, 0, 5s)...
D 10:08:32.895 [McuMgr] gatt.requestConnectionPriority(HIGH)
A 10:08:32.916 [McuMgr] Sending (9 bytes) Header (Version: 1, Op: 0, Flags: 0, Len: 1, Group: 0, Seq: 0, Command: 8) CBOR {}
I 10:08:33.019 Connection parameters updated (interval: 12.5ms, latency: 0, timeout: 5000ms)
I 10:08:33.042 [McuMgr] Connection parameters updated (interval: 12.5ms, latency: 0, timeout: 5000ms)
V 10:08:33.047 [McuMgr] Writing characteristic da2e7828-fbce-4e01-ae9e-261174997c48 (WRITE COMMAND)
D 10:08:33.050 [McuMgr] characteristic.setValue(0x0800000100000008A0)
D 10:08:33.055 [McuMgr] characteristic.setWriteType(WRITE COMMAND)
D 10:08:33.058 [McuMgr] gatt.writeCharacteristic(da2e7828-fbce-4e01-ae9e-261174997c48)
I 10:08:33.071 [McuMgr] Data written to da2e7828-fbce-4e01-ae9e-261174997c48
I 10:08:33.107 [McuMgr] Notification received from da2e7828-fbce-4e01-ae9e-261174997c48, value: (0x) 01-00-00-06-00-00-00-08-BF-62-72-63-08-FF
A 10:08:33.134 [McuMgr] Received Header (Version: 0, Op: 1, Flags: 0, Len: 6, Group: 0, Seq: 0, Command: 8) CBOR {"rc":8}
W 10:08:33.141 [McuMgr] Error: NOT_SUPPORTED (8)
A 10:08:33.217 [McuMgr] Sending (9 bytes) Header (Version: 1, Op: 0, Flags: 0, Len: 1, Group: 1, Seq: 1, Command: 0) CBOR {}
V 10:08:33.222 [McuMgr] Writing characteristic da2e7828-fbce-4e01-ae9e-261174997c48 (WRITE COMMAND)
D 10:08:33.225 [McuMgr] characteristic.setValue(0x0800000100010100A0)
D 10:08:33.228 [McuMgr] characteristic.setWriteType(WRITE COMMAND)
D 10:08:33.231 [McuMgr] gatt.writeCharacteristic(da2e7828-fbce-4e01-ae9e-261174997c48)
I 10:08:33.266 [McuMgr] Data written to da2e7828-fbce-4e01-ae9e-261174997c48
I 10:08:33.356 [McuMgr] Notification received from da2e7828-fbce-4e01-ae9e-261174997c48, value: (0x) 01-00-00-86-00-01-01-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-A8-0C-14-26-22-AB-81-A6-63-48-9E-94-22-A1-25-A8-64-48-99-50-DA-60-CD-75-08-9D-A6-84-2D-B4-6A-CB-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:08:33.391 [McuMgr] Received Header (Version: 0, Op: 1, Flags: 0, Len: 134, Group: 1, Seq: 1, Command: 0) CBOR {"images":[{"slot":0,"version":"0.0.0","hash":"qAwUJiKrgaZjSJ6UIqElqGRImVDaYM11CJ2mhC20ass=","bootable":true,"pending":false,"confirmed":true,"active":true,"permanent":false}],"splitStatus":0}
V 10:08:33.437 [McuMgr] Uploading firmware...
V 10:08:34.275 [McuMgr] Disconnecting...
D 10:08:34.281 [McuMgr] gatt.disconnect()
D 10:08:34.329 [McuMgr] [Callback] Connection state changed with status: 0 and new state: 0 (DISCONNECTED)
I 10:08:34.334 [McuMgr] Disconnected
D 10:08:34.339 [McuMgr] gatt.close()

As you can clearly see, i get a [McuMgr] ERROR: Not_supported (8), but that feels extremely generic and does not help us in debugging the behavior.

I have tried using the peripheral_LBS example by adding the DFU support (resulting size was 156 kB) and such firmware loads correctly into the board and starts regularly, which leads us to believe that total firmware size is the issue.

Could anyone confirm whethere a 188 kB f/w would work as DFU FOTA replacement?

In case it would not, how much space would we need to leave on the on-board FLASH for the functionality to properly work?

[AHaug]

Ah, yes I remember the previous case (since I supported it). In that case, NCSDK-20567 was the issue since their application was above 223157bytes.

Could you also upload your mcuboot.conf (and mcuboot.overlay)? They should be within a child_image/ folder since you're working with 1.9.1. 

I also assume based on your memory partition and configuration that you're not using an external flash, but nonetheless, could you verify that this is the case as well?

Another option that might work is to compare the sample with https://github.com/hellesvik-nordic/samples_for_nrf_connect_sdk/tree/v2.2.0/bootloader_samples/smp. These unofficial samples are for ncs 2.2.0 and are written by a colleague of mine, but if I remember correct they may also be compatible with NCS 1.9.1.

Kind regards,
Andreas

[Cloudscraper]

Hello and good morning Andreas,

1. Our project does not currently include any mcuboot.conf nor mcuboot.overlay files. Are these mandatory? Are these auto-generated and not working properly?

2. Our design is based on the Fanstel BC833M/E Compact BLE 5.2, Thread, Zigbee Module which contains the NRF52833 Microcontroller with its own flash. No external Flash memory has been added to the design.

3. I will start looking at this application: how would you suggest to integrate this in our design? I will start by comparing the prj.conf in  the application you suggested with the prj.conf I have attached to my original post (which is our most up-to-date configuration)

[Cloudscraper]

An additional note regarding point number 3 (bootloader_samples).

I tried doing a diff between that prj.conf and ours and creating a minimal BLE DFU configuration to test.

These two configuration lines which are part of the v2.2 bootloader_samples prj are unknown symbols for the 1.9.1 nRF Connect:

CONFIG_MCUMGR_SMP_REASSEMBLY_BT=y

CONFIG_OS_MGMT_MCUMGR_PARAMS=y

Any equivalences so I can complete the test at the very least?

[AHaug]

Cloudscraper said:

1. Our project does not currently include any mcuboot.conf nor mcuboot.overlay files. Are these mandatory? Are these auto-generated and not working properly?

If you need configurations that are different from the default MCUboot (which is included with CONFIG_BOOTLOADER_MCUBOOT=y which you have), you will need to set them in the child image configuration is well. An example of this is if you would've needed to set up an external flash in the case where your secondary mcuboot partition should be located on the external flash. In that case it could look something like this (which is a sample i've created for that specific scenario).  : https://github.com/aHaugl/samples_for_NCS/blob/main/bootloader/spi/smp_ble_feat_spi/child_image/mcuboot.conf. This is the reason for why I wanted a verification on item 2 regarding the external flash. Since you don't have one, it should be enough

Cloudscraper said:

3. I will start looking at this application: how would you suggest to integrate this in our design? I will start by comparing the prj.conf in  the application you suggested with the prj.conf I have attached to my original post (which is our most up-to-date configuration)

First I would compare the configurations, which I see you've done. 

Cloudscraper said:

Any equivalences so I can complete the test at the very least?

At the time when NCS 1.8 was new, a previous colleague of mine wrote this guide:  Add DFU support to your application (which results in the sample here https://github.com/simon-iversen/sdk-nrf/tree/ble_dfu_peripheral_lbs/samples/bluetooth/peripheral_lbs). Maybe this is an even better angle of attack than the NCS v2.2.0 sample. There was a big change in either 2.3.0 or 2.2.0 w.r.t DFU and MCUboot, and I thought I remembered correct that they were introduced in v2.3.0. Looks like it might've been v2.2.0 instead.

This sample does not have any child_image configuration for mcuboot, so looks like we can disregard item 1 unless you spot anything in the example I used to illustrate that may match your project.

Apologies for just hammering you with links and resources that almost fit your needs, but I hope they will be helpful in the end. Let me know about the guide and resulting sample if this matches closer to your project in 1.9.1

Kind regards,
Andreas

[Cloudscraper]

Hello again, I am well prepared to answer this time, since it is something I have already explored.

During last week, I tried using the peripheral_LBS prj.conf, then adding the DFU support by following the tutorial you mentioned (that I had fortunately already found), and the derived design ended up working fine for us. 

The resulting app_update.bin with peripheral_LBS example + DFU support ended up being 156 kB (instead of the original 188kB) and it performs the operations correctly.

This cementified the feeling that the file size could be the source of the issue.

I think it is important for me to explicitly state a side-effect or connected issue.

Our client has requested whitelisting/bonding functionality for management of the DFU, that is why you see additional flags in the original prj.conf (we tried following examples and tutorial on Nordic resources)

Our firmware revisions before the addition of these parameters were performing any DFU operations fine, but ever since we added whitelist/bonding we cannot get the system to work the way we would want to.

In particular, this is the malfunction we are observing, in detail:

- let's call the firmware version with DFU+whitelist v1.8

- let's assume that we want to replace it with peripheral_LBS+DFU firmware

- this operation completes correctly

- then we connect to the "new" BLE device (name and characteristics have obviously changed) and we try flashing back the DFU+Whitelist v1.8 through another DFU operation

- we cannot complete this "cycle" of operation, cannot return to v1.8 except by using the J-Link physical programmer.

Kind regards,

Michele