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]

Hi,

Yes, this might be related to NCSDK-20567: Partitioning limitation with MCUboot swap move found here: https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/releases_and_maturity/known_issues.html#mcuboot (make sure to check of "All versions" at the top of the page).

"The swap algorithm in MCUboot (especially the default one - swap_move) requires some extra space to perform the swap move operation, so not entire partition space can be spent for the image. If the incoming image is too large, then the update will be impossible. If the installed image is too large, then undefined behavior might occur.

Workaround: Make sure that the DFU update images are of a specific maximum size. Typically, for the nRF52, nRF53, and nRF91 devices, the size of the application must be less than mcuboot_primary_size - 80 - (mcuboot_primary_size/ 4096) * 12 -4096. Some additional margin is suggested."

How large is the primary (and thus secondary) mcuboot partition sizes in your application? 

Kind regards,
Andreas

[Cloudscraper]

This is the partition_manage report for my app:

partition_manager_Cloudscraper.zip

[AHaug]

Thank you. This partitioning is with dynamic partitioning, right? I.e you don't have a pm_static.yml within your project? Could you also confirm that you're working with NCS v1.9.1 (based on the command ran within the memory report)?

228000-80-(228000/4096)*12-4096 = 223157bytes > 188kB, so you should be good with regards to this.. I will have to come back to you after looking closer into it tomorrow

Kind regards,
Andreas

[Cloudscraper]

I can confirm that our project that does not contain a pm_static.yml 

Thanks,
The only other aspect I am not sure about is the prj.conf flags.

[Cloudscraper]

I can also confirm we are working with NCS v1.9.1

as a sidenote, the prj.conf I have pasted in the first post is the current configuration we are using which does not allow proper DFU FOTA, while I am now going to attach a previous prj.conf that does allow DFU (but does not have whitelist functions):

#PREVIOUS VERSION OF 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="***"
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

CONFIG_STDOUT_CONSOLE=y
CONFIG_LOG=y
CONFIG_USB_DRIVER_LOG_LEVEL_ERR=y
CONFIG_USB_DEVICE_LOG_LEVEL_ERR=y
CONFIG_SERIAL=y
CONFIG_UART_INTERRUPT_DRIVEN=y
CONFIG_UART_LINE_CTRL=y

CONFIG_WDT_LOG_LEVEL_DBG=y
CONFIG_WATCHDOG=y
CONFIG_WDT_DISABLE_AT_BOOT=n

I have previously visited this topic you worked on: (+) [McuMgr] Error : NOT_SUPPORTED during DFU by BLE with MCUBoot - Nordic Q&A - Nordic DevZone - Nordic DevZone and this thread is the reason why we started thinking about memory allocation issues

[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