• State Not Answered
  • Replies 15 replies
  • Subscribers 70 subscribers
  • Views 275 views
  • Users 0 members are here
Attachments (1) Download All
Nordic Case Info
  • Case ID: 339358
Options

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?

  • 0

    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

  • 0 in reply to Cloudscraper

    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

  • 0 in reply to AHaug

    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.

  • 0 in reply to 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

Related
Terms of service