Unable to swap DFU image in dual-slot MCUboot setup on nRF52832 (bootable: false)

Title: Unable to swap DFU image in dual-slot MCUboot setup on nRF52832 (bootable: false)

Environment:

  • Board: nRF52 DK (nrf52dk_nrf52832)

  • MCUboot: v1.9.0 (built via Zephyr 3.5.99, NCS v2.5)

  • Toolchain: Zephyr SDK 0.16.5

  • West: 1.2.0

  • cmake: 3.21.0

  • Python: 3.9.13

  • mcumgr (CLI): 0.0.0-dev (Nordic-published)

  • Build command:

    west build --pristine --board nrf52dk_nrf52832 \
      -DCONF_FILE=debug.conf \
      -DBOARD_ROOT=... c:/Projects/THZ/GWB/GWB/nrf52_application
    

Partition layout (pm_static.yml):

storage_partition:
  address: 0x7A000
  size:    0x6000
  region:  flash_primary

MCUboot config (child_image/mcuboot.conf):

CONFIG_MCUBOOT_SERIAL=y
CONFIG_BOOT_SERIAL_UART=y
CONFIG_BOOT_SERIAL_WAIT_FOR_DFU=y
CONFIG_BOOT_SERIAL_WAIT_FOR_DFU_TIMEOUT=5000
CONFIG_MCUBOOT_SERIAL_DIRECT_IMAGE_UPLOAD=y
CONFIG_BOOT_SWAP_USING_MOVE=y
CONFIG_BOOT_VALIDATE_SLOT0=y
CONFIG_BOOT_SERIAL_NO_APPLICATION=y

(All other defaults from NCS mcuboot.conf.)

Debug config (debug.conf, acts as prj.conf in my build configuration):

CONFIG_BOOTLOADER_MCUBOOT=y
CONFIG_MCUBOOT_IMG_MANAGER=y
CONFIG_IMG_MANAGER=y
# BLE, UART, logging, GATT client, etc.

Application code:

  • main.c calls boot_write_img_confirmed() at startup

  • No other mcuboot-specific code changes

Build outputs:

  • zephyr/app_update.bin is generated and uploaded via:

    mcumgr --conntype serial --connstring "dev=COM13,baud=115200" \
      image upload -n 2 debug_1/zephyr/app_update.bin
    
  • Upload succeeds without errors

Observed behavior:

> mcumgr ... image list
Images:
 image=0 slot=0
    version: 0.0.0
    bootable: false
    flags:
    hash: bf59d59256986ab12a8ca770c8ebb5694dd69cdb26cc3ea4fc6853cb536b9992
 image=0 slot=1
    version: 0.0.0
    bootable: false
    flags:
    hash: 62cf5d15a4b457ed9af4cb887def7ab1a4c2aaa00e65b3fa692bc181a9aa4925
Split status: N/A (0)
  • Both slots show bootable=false

  • Trying to test the image:

    mcumgr ... image test 62cf5d15a4b457ed9af4cb887def7ab1a4c2aaa00e65b3fa692bc181a9aa4925
    Error: 8
    
  • Error 8 indicates MCUMGR_ERR_NOT_SUPPORTED or invalid parameter

What I've tried (no success):

  1. Adding a top-level VERSION file

  2. Enabling various CONFIG_MCUMGR_* options for image management

Expected behavior:

  • After upload:

    • Slot 1 should list with bootable: true

  • mcumgr image test <hash> should return success and mark the image pending swap

  • On reboot, MCUboot should perform swap/move and run the new firmware

Questions:

  1. Why does MCUboot list bootable: false despite signing with the default MCUBoot key?

  2. Why does image test return Error 8?

  3. What is missing in my NCS/Zephyr build to produce a bootable image?

  4. Are there any known issues or patches for Zephyr 3.5.99 mcuboot on nRF52?

Any insights into required CMake/Kconfig changes or build steps to restore proper DFU dual-slot swapping would be greatly appreciated!

— Thanks in advance for your help!

Parents
  • Hello,

    Only a limited subset of the mcumgr commands are implemented in serial recover mode (https://docs.mcuboot.com/serial_recovery.html) and the update is expected to be uploaded directly to the primary slot.

    Both slots show bootable=false

    This seems to be a limitation when using serial recovery mode. The flag is always shown as false.

    Adding a top-level VERSION file

    Support for using VERSION filer was added in a later SDK release. In this version you can use the CONFIG_MCUBOOT_IMGTOOL_SIGN_VERSION symbol to specify the version to sign the image with. E.g., CONFIG_MCUBOOT_IMGTOOL_SIGN_VERSION="2.0.0".

    • mcumgr image test <hash> should return success and mark the image pending swap

    • On reboot, MCUboot should perform swap/move and run the new firmware

    Swap and marking the image as pending is only supported when doing DFU via the app (https://academy.nordicsemi.com/courses/nrf-connect-sdk-intermediate/lessons/lesson-9-bootloaders-and-dfu-fota/topic/exercise-1-dfu-over-uart/).

    • Why does MCUboot list bootable: false despite signing with the default MCUBoot key?

    • Why does image test return Error 8?

    • What is missing in my NCS/Zephyr build to produce a bootable image?

    • Are there any known issues or patches for Zephyr 3.5.99 mcuboot on nRF52?

    1. The flag is always shown as false in serial recovery mode

    2. 8 ('MGMT_ERR_ENOTSUP') indicates that the command is not supported/implemented.

    3. Does the bootloader not boot the main app on normal boot when you are not entering serial recovery mode?

    4. I can't think of anything that should be relevant. I also tried to test it here now to be sure, but it worked on my end. Difference is that I uploaded the image directly to the primary slot (-n 1).

    hello_world_serial_recovery.zip

    Best regards,

    Vidar

  • Hi Vidar,

    Thank you for your response. I followed all the instructions at the link you provided me with for DFU via the app, but when I try to run the 'mcumgr ... image list', I get an NMP timeout, so I'm unable to test or confirm the new image. I am also unable to successfully run 'mcumgr ... image upload ...'. Below is my prj.conf:

    # Enable the UART driver
    CONFIG_UART_ASYNC_API=y
    CONFIG_NRFX_UARTE0=y
    CONFIG_SERIAL=y
    CONFIG_CONSOLE=y
    CONFIG_UART_CONSOLE=y
    
    # Enable Kernel Synchronization Features (Includes k_event)
    CONFIG_EVENTS=y
    
    # Enable the BLE stack with GATT Client configuration
    CONFIG_BT=y
    CONFIG_BT_CENTRAL=y
    CONFIG_BT_FILTER_ACCEPT_LIST=y
    CONFIG_BT_GATT_CLIENT=y
    CONFIG_BT_AUTO_PHY_UPDATE=n
    
    CONFIG_BT_MAX_PAIRED=10
    CONFIG_BT_MAX_CONN=10
    
    # Enable larger ATT MTU
    CONFIG_BT_ATT_PREPARE_COUNT=5
    CONFIG_BT_L2CAP_TX_MTU=247
    CONFIG_BT_BUF_ACL_RX_SIZE=251
    CONFIG_BT_BUF_ACL_TX_SIZE=251
    CONFIG_BT_ATT_ENFORCE_FLOW=y
    
    # Configure maximum supported MTU
    CONFIG_BT_L2CAP_TX_MTU=247
    CONFIG_BT_GATT_CLIENT=y
    CONFIG_BT_GATT_DYNAMIC_DB=y
    CONFIG_BT_GATT_AUTO_DISCOVER_CCC=y
    
    CONFIG_BT_GATT_DM_MAX_ATTRS=10
    
    # Number of concurrent GATT procedures
    CONFIG_BT_CONN_TX_MAX=7
    CONFIG_BT_BUF_ACL_TX_COUNT=7
    CONFIG_BT_BUF_ACL_RX_COUNT=7
    
    CONFIG_BT_GATT_DM=y
    CONFIG_BT_CONN_CTX=y
    CONFIG_HEAP_MEM_POOL_SIZE=5120
    
    # Config logger
    CONFIG_LOG=n
    CONFIG_USE_SEGGER_RTT=n
    CONFIG_LOG_BACKEND_RTT=n
    CONFIG_LOG_BACKEND_UART=n
    CONFIG_LOG_PRINTK=n
    
    CONFIG_UART_ASYNC_ADAPTER=y
    CONFIG_UART_INTERRUPT_DRIVEN=y
    CONFIG_UART_USE_RUNTIME_CONFIGURE=y
    
    CONFIG_FLASH=y
    CONFIG_FLASH_PAGE_LAYOUT=y
    CONFIG_MPU_ALLOW_FLASH_WRITE=y
    CONFIG_SOC_FLASH_NRF_EMULATE_ONE_BYTE_WRITE_ACCESS=y
    
    CONFIG_APP_LOG_LEVEL=4
    CONFIG_ASSERT=y
    
    CONFIG_BT_GATT_DM_DATA_PRINT=y
    
    # MCU BOOT config
    CONFIG_BOOTLOADER_MCUBOOT=y
    
    # Enable MCUMGR 
    CONFIG_MCUMGR=y
    CONFIG_MCUMGR_GRP_OS=y
    CONFIG_MCUMGR_GRP_IMG=y
    CONFIG_MCUMGR_TRANSPORT_UART=y
    CONFIG_NET_BUF=y
    CONFIG_ZCBOR=y
    CONFIG_CRC=y
    CONFIG_IMG_MANAGER=y
    CONFIG_STREAM_FLASH=y
    CONFIG_FLASH_MAP=y 
    CONFIG_BASE64=y
    
    CONFIG_GWB_HARDWARE=y

    Do any of my configs interfere with the ones needed for DFU over UART? I can confirm that setting 

    CONFIG_UART_CONSOLE=n in prj.conf does not fix the problem (it is however set to 'n' in mcuboot.conf). If you do not see any issue here, do you have any idea as to what could be causing the issue? Thank you in advance.

    Best regards,
    Gabriel
Reply
  • Hi Vidar,

    Thank you for your response. I followed all the instructions at the link you provided me with for DFU via the app, but when I try to run the 'mcumgr ... image list', I get an NMP timeout, so I'm unable to test or confirm the new image. I am also unable to successfully run 'mcumgr ... image upload ...'. Below is my prj.conf:

    # Enable the UART driver
    CONFIG_UART_ASYNC_API=y
    CONFIG_NRFX_UARTE0=y
    CONFIG_SERIAL=y
    CONFIG_CONSOLE=y
    CONFIG_UART_CONSOLE=y
    
    # Enable Kernel Synchronization Features (Includes k_event)
    CONFIG_EVENTS=y
    
    # Enable the BLE stack with GATT Client configuration
    CONFIG_BT=y
    CONFIG_BT_CENTRAL=y
    CONFIG_BT_FILTER_ACCEPT_LIST=y
    CONFIG_BT_GATT_CLIENT=y
    CONFIG_BT_AUTO_PHY_UPDATE=n
    
    CONFIG_BT_MAX_PAIRED=10
    CONFIG_BT_MAX_CONN=10
    
    # Enable larger ATT MTU
    CONFIG_BT_ATT_PREPARE_COUNT=5
    CONFIG_BT_L2CAP_TX_MTU=247
    CONFIG_BT_BUF_ACL_RX_SIZE=251
    CONFIG_BT_BUF_ACL_TX_SIZE=251
    CONFIG_BT_ATT_ENFORCE_FLOW=y
    
    # Configure maximum supported MTU
    CONFIG_BT_L2CAP_TX_MTU=247
    CONFIG_BT_GATT_CLIENT=y
    CONFIG_BT_GATT_DYNAMIC_DB=y
    CONFIG_BT_GATT_AUTO_DISCOVER_CCC=y
    
    CONFIG_BT_GATT_DM_MAX_ATTRS=10
    
    # Number of concurrent GATT procedures
    CONFIG_BT_CONN_TX_MAX=7
    CONFIG_BT_BUF_ACL_TX_COUNT=7
    CONFIG_BT_BUF_ACL_RX_COUNT=7
    
    CONFIG_BT_GATT_DM=y
    CONFIG_BT_CONN_CTX=y
    CONFIG_HEAP_MEM_POOL_SIZE=5120
    
    # Config logger
    CONFIG_LOG=n
    CONFIG_USE_SEGGER_RTT=n
    CONFIG_LOG_BACKEND_RTT=n
    CONFIG_LOG_BACKEND_UART=n
    CONFIG_LOG_PRINTK=n
    
    CONFIG_UART_ASYNC_ADAPTER=y
    CONFIG_UART_INTERRUPT_DRIVEN=y
    CONFIG_UART_USE_RUNTIME_CONFIGURE=y
    
    CONFIG_FLASH=y
    CONFIG_FLASH_PAGE_LAYOUT=y
    CONFIG_MPU_ALLOW_FLASH_WRITE=y
    CONFIG_SOC_FLASH_NRF_EMULATE_ONE_BYTE_WRITE_ACCESS=y
    
    CONFIG_APP_LOG_LEVEL=4
    CONFIG_ASSERT=y
    
    CONFIG_BT_GATT_DM_DATA_PRINT=y
    
    # MCU BOOT config
    CONFIG_BOOTLOADER_MCUBOOT=y
    
    # Enable MCUMGR 
    CONFIG_MCUMGR=y
    CONFIG_MCUMGR_GRP_OS=y
    CONFIG_MCUMGR_GRP_IMG=y
    CONFIG_MCUMGR_TRANSPORT_UART=y
    CONFIG_NET_BUF=y
    CONFIG_ZCBOR=y
    CONFIG_CRC=y
    CONFIG_IMG_MANAGER=y
    CONFIG_STREAM_FLASH=y
    CONFIG_FLASH_MAP=y 
    CONFIG_BASE64=y
    
    CONFIG_GWB_HARDWARE=y

    Do any of my configs interfere with the ones needed for DFU over UART? I can confirm that setting 

    CONFIG_UART_CONSOLE=n in prj.conf does not fix the problem (it is however set to 'n' in mcuboot.conf). If you do not see any issue here, do you have any idea as to what could be causing the issue? Thank you in advance.

    Best regards,
    Gabriel
Children
No Data
Related