• State Not Answered
  • Replies 5 replies
  • Subscribers 25 subscribers
  • Views 336 views
  • Users 0 members are here
Attachments (2) Download All
Nordic Case Info
  • Case ID: 287801
Options

Update Net core with netboot through MCUBoot over serial USB.

user102664

Hello,

The following is for a custom application but I have also tested this with the base peripheral_uart example with the same result.

I have an application which uses a custom firmware on both the application core and network core and have configured the app project with CONFIG_BOOTLOADER_MCUBOOT and CONFIG_PCD, configured the net project with CONFIG_SECURE_BOOT, and added the net as a child image to the app to successfully build and produce app_update.bin and net_core_app_update.bin.

When the DK is placed into DFU mode and connected over USB, I am able to use mcumgr to send app_update.bin to the APP core. The console displays the following:

I: Erasing sector at offset 0x0
I: Writing at 0x0 until 0x124
.....

However, when I try to send  net_core_app_update.bin, I get the same output as above and after reboot the serial console shows that I enter a bootloop from what I assume is mcumgr incorrectly writing the net image to the app flash.

Is there any documentation available on how to instruct mcumgr to write net_core_app_update.bin to netboot over IPC or otherwise update the NET core over MCUBoot's USB connection.

Parents
  • 0

    Hi,

    Which nRF Connect SDK version are you using?

    Are you still using the methods you described in this case for including your child image? https://devzone.nordicsemi.com/f/nordic-q-a/72840/nrf5340-multi-image-example-configuration-help

    CONFIG_PCD should be enabled in mcuboot, not in the app project. In the project directory, create a directory named child_image containing a file named mcuboot.conf. mcuboot.conf should contain the line:

    CONFIG_PCD=y

    This will add the config to mcuboot. https://developer.nordicsemi.com/nRF_Connect_SDK/doc/1.5.1/nrf/ug_multi_image.html?highlight=multi%20image#image-specific-variables

  • 0 in reply to user81283

    We are using SDK 1.6.0. 

    I have made the changes, putting CONFIG_PCD in our mcuboot.conf instead of prj.conf and repeated the test procedure but it still seems to be flashing to the APP core starting from 0x0.

    The original changes to the base 1.6.0 SDK are the mcuboot.conf below and CONFIG_BOOTLOADER_MCUBOOT=y set in prj.conf in examples/bluetooth/peripheral_uart project.

    CONFIG_LOG=n
# The build won't fit on the partition allocated for it without size
# optimizations.
CONFIG_SIZE_OPTIMIZATIONS=y
CONFIG_PM_PARTITION_SIZE_MCUBOOT=0x10000
CONFIG_PCD=y

# Serial
CONFIG_SERIAL=y
CONFIG_UART_NRFX=y
CONFIG_UART_INTERRUPT_DRIVEN=y
CONFIG_UART_LINE_CTRL=y

# MCUBoot serial
CONFIG_GPIO=y
CONFIG_MCUBOOT_SERIAL=y
CONFIG_BOOT_SERIAL_CDC_ACM=y
CONFIG_BOOT_SERIAL_DETECT_PORT="GPIO_0"
CONFIG_BOOT_SERIAL_DETECT_PIN=23

# Required by USB
CONFIG_MULTITHREADING=y

# USB
CONFIG_USB=y
CONFIG_USB_DEVICE_STACK=y
CONFIG_USB_DEVICE_PRODUCT="MCUBOOT"
CONFIG_USB_CDC_ACM=y
CONFIG_USB_COMPOSITE_DEVICE=n
CONFIG_USB_MASS_STORAGE=n

    After that, to capture the attached logs and start debugging, I increased the mcuboot partition size to 128k and shifted the secure partition slots up while reducing them by 32k each. I don't believe this would cause a problem with netboot communications as I can still flash the app core without issue.

    The command I am using to flash the app core is is:

    mcumgr --conntype=serial --connstring='/dev/ttyACM3,baud=115200' image upload build/zephyr/app_update.bin

    And for the net core I use:

    mcumgr --conntype=serial --connstring='/dev/ttyACM3,baud=115200' image upload build/zephyr/net_core_app_update.bin

  • 0 in reply to user102664

    Could you try this sequence:

    mcumgr --conntype=serial --connstring="dev=/dev/ttyACM3,baud=115200" image upload -n 3 build/zephyr/net_core_app_update.bin
#wait min. 2 minutes to allow Network Core to copy image.
mcumgr --conntype=serial --connstring="dev=/dev/ttyACM3,baud=115200" image upload build/zephyr/app_update.bin
mcumgr --conntype=serial --connstring="dev=/dev/ttyACM3,baud=115200" image list
mcumgr --conntype=serial --connstring="dev=/dev/ttyACM3,baud=115200" reset

Reply
  • 0 in reply to user102664

    Could you try this sequence:

    mcumgr --conntype=serial --connstring="dev=/dev/ttyACM3,baud=115200" image upload -n 3 build/zephyr/net_core_app_update.bin
#wait min. 2 minutes to allow Network Core to copy image.
mcumgr --conntype=serial --connstring="dev=/dev/ttyACM3,baud=115200" image upload build/zephyr/app_update.bin
mcumgr --conntype=serial --connstring="dev=/dev/ttyACM3,baud=115200" image list
mcumgr --conntype=serial --connstring="dev=/dev/ttyACM3,baud=115200" reset

Children
  • 0 in reply to user81283

    I have tried with the commands you provided and it still does not work. For updating the net core image, I gave it 3 minutes after the first since the upload itself took 2min 30sec.

    The output of `image list` was:

    Images:
 image=0 slot=0
    version: 0.0.0.0
    bootable: false
    flags:
    hash: Unavailable
Split status: N/A (0)

    for both a fresh flash with west `flash --erase` and after performing the update sequence provided in bootloader mode.

    This was tested with the following changes to mcuboot.conf from the patch provided.

    CONFIG_LOG=n
CONFIG_LOG_BACKEND_UART=n
CONFIG_PM_PARTITION_SIZE_MCUBOOT=0x10000

    And removal of the app overlay to keep the partitions in their original positions.

    To verify if the net core is updated, I flash normally then build again with the boot banner string changed. After performing the update sequence only the app image contains the changed boot banner.

    Additionally I am using mcumgr `mcumgr 0.0.0-dev`. Not sure if this is correct but it was pulled from `go install github.com/apache/mynewt-mcumgr-cli/mcumgr@latest`. Built with go 1.18.1.

  • 0 in reply to user81283

    Hi,

    I found this example, https://devzone.nordicsemi.com/guides/nrf-connect-sdk-guides/b/software/posts/device-firmware-update-dfu-with-mcuboot-bootloader which discusses setting up MCUBoot on nrf52840 and noticed the `image list` output is the same.

    Which brings me to my question, does any NCS version of the MCUboot bootloader support multi slot updates at all? I noticed even when updating the APP core it always writes directly to slot 0 (only slot listed) and when the bootloader process is interrupted the device becomes bricked.

    This seems key as it looks like the PCD library updates the net core through the scratch partition when net_core_app_update.bin is written to it (default 3) which is not present in the image list output.

    To further test this, I deleted all dts entries for slot0_ns_slot1 slot1_ns from the nrf5340_cpuapp_partition_conf.dts and confirmed in build/zephyr/zephyr.dts that those partitions are not present. The result was the build succeeded which makes me believe that multi slot bootloader builds are not supported on this platform.

    In bootloader/mcuboot/boot/zephyr/Kconfig BOOT_SWAP_USING_MOVE is default y on the NRF platform while the default when not on NRF is BOOT_SWAP_USING_SCRATCH. This further makes me believe it is not supported. I have checked both my current working NCS sdk tag: v1.6.0 as well as the current latest tag: v1.9.1 with the same results.

    If multi slot upgrades with scratch is supported, could you point me to a working example from the SDK where this is done. 

    For reference, I also tested the base MCUBoot in the zephyrprojectRTOS (tag: zephyr-v2.6.0) on a non NRF devboard and it failed to compile without slot1 and scratch partitions present.

Related
Terms of service