• State Not Answered
  • Replies 15 replies
  • Subscribers 70 subscribers
  • Views 290 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?

Parents
  • 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
    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

  • 0 in reply to AHaug

    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

  • 0 in reply to Cloudscraper

    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 

  • 0 in reply to AHaug

    Hello Andreas,

    these three function calls are indeed present in my code.

    To be more accurate, the 

    os_mgmt_register_group();
    img_mgmt_register_group();

    are at the beginning of the main() function.


    The smp_bt_register() is used as follows:

    void init_ble()
{
    printk("build time: " __DATE__ " " __TIME__ "\n");
    smp_bt_register();

    int err = bt_enable(NULL);
    if (err)
    {
        printk("Bluetooth init failed (err %d)\n", err);
        return;
    }

    printk("Bluetooth initialized\n");

    if (IS_ENABLED(CONFIG_SETTINGS))
    {
        settings_load();
    }

    k_work_submit(&advertise_acceptlist_work);
}

    Could this positioning be weird or causing issues?

  • 0 in reply to Cloudscraper

    I have been doing some tests today and I noticed a peculiar behaviour.


    Assuming the firmware revision residing on the board is called 1.8b, I can upload another version (with minimal differences) called 1.8c and I can keep doing ping-pong between these two.


    What I notice is that when I try DFUing from 1.8c to 1.8b i get a GATT CONN TIMEOUT error in nRF Connect logger, but then when the device reboots it is showing the correct firmware revision BLE characteristic.


    Is it possible that in its current state the device can ping-pong only among the #1 and #2 partition contents but not be able to replace those with external FW?

Reply
  • 0 in reply to Cloudscraper

    I have been doing some tests today and I noticed a peculiar behaviour.


    Assuming the firmware revision residing on the board is called 1.8b, I can upload another version (with minimal differences) called 1.8c and I can keep doing ping-pong between these two.


    What I notice is that when I try DFUing from 1.8c to 1.8b i get a GATT CONN TIMEOUT error in nRF Connect logger, but then when the device reboots it is showing the correct firmware revision BLE characteristic.


    Is it possible that in its current state the device can ping-pong only among the #1 and #2 partition contents but not be able to replace those with external FW?

Children
No Data
Related
Terms of service