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

[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

[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

[AHaug]

Cloudscraper said:

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. 

Ah, of course this is what you was referring to when you mentioned the peripheral lbs with dfu support. My bad for misunderstanding that.

Cloudscraper said:

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.

Ok, I'm following.

Are you using some sort of versioning in your firmware, in for instance the initial v1.8? I'm considering if what you're seeing is caused by downgrade prevention that's happening when you try to go back to v1.8 from peripheral_lbs+DFU again. Does the result change if you do:

1. v1.8 update to peripheral_lbs+dfu
2. peripheral_lbs+dfu update to a modified v1.8
   1. where the modification you do is either a print and/or update the versioning to a newer revision

We can also exclude if this is a size issue by trying to repeat the same issue if you build with a release configuration unless you're already doing this

[Cloudscraper]

Hello,

sorry for the delayed response, i've been away from the office for a couple days.

Our versioning is (should be?) only on GIT, I do not think it is caused by any firmware configuration specifically.

In terms of what is shown on the Nordic S/W, we are just modifying a constant that gets propagated to a BLE characteristic.

I have been referring to the aforementioned v1.8 because it's the first version where the client has requested the whitelist/accept list mechanism.

Every version before v1.8 has been working properly in terms of DFU usage.

____________________________________________

Replying to your request specifically:

1. works correctly

2. does not work, nRF Connect does not complete the operation correctly, does not upload the firmware and throws the error mentioned before (MCUMGR ERROR NOT SUPPORTED (8) )

_____________________________________________

We can also exclude if this is a size issue by trying to repeat the same issue if you build with a release configuration unless you're already doing this

This is not clear to me, would you mind explaining how we could try this solution?

Thanks in advance

MM

[AHaug]

Hi MM,

No worries about the response time

Cloudscraper said:

Our versioning is (should be?) only on GIT, I do not think it is caused by any firmware configuration specifically.

Given that you don't use this versioning for anything in the build, then downgrade prevention  shouldn't be the reason.

Cloudscraper said:

We can also exclude if this is a size issue by trying to repeat the same issue if you build with a release configuration unless you're already doing this

Apologies for the poorly wording. By this I mean if you're able to remove features that you don't need in production such as for instance logging, to create a smaller release-version of your firmware that you can test to DFU to see if it is indeed a flash size issue. As mentioned, your application size is well outside the boundary that triggers NCSDK-20567 

Going back a bit to the original issue, 

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)
Group 0: -> OS management

indicates that the reset command is not supported, which could suggest that the following two configurations

CONFIG_MCUMGR_CMD_IMG_MGMT=y
CONFIG_MCUMGR_CMD_OS_MGMT=y 

and these three lines (in your application) is not set

os_mgmt_register_group();
img_mgmt_register_group();
smp_bt_register();

I see that you have the configs in the prj.conf you uploaded previous week, but could you verify if you've set these 3 lines? Similar to the first sample in  Add DFU support to your application that I previously linked

Kind regards,
Andreas