Multi-Image DFU project structure

Hello,

I am working on a project with the nrf5340, on ncs version 2.1.2, though I plan to bring it into v2.2.0.

I have been working on this sample on the side because Multi-Image DFU is a must for my application. While there are issues unresolved on the thread, (about iOS being faulty when running DFU more than once), it is the only sample that has uploaded 2 images through BLE and successfully updated the device. However, I have run into some complications in implementing this code into my firmware.

The sample structure is very simple:

mcu_smp_ble_simultaneous:
    - child_image
        -mcuboot.conf
    - src
        - main.c
        - bluetooth_smp.c
        - bluetooth_smp.h
    app.overlay
    CMakeLists.txt
    prj.conf
    

My project is more involved. I am struggling to figure out where the mcuboot.conf will be added, and how to add its configurations for the mcuboot bootloader. I have several questions that I have been trying to research, so I am reaching out for help here while I continue to try.

When building my project with the following CMakeLists.txt, I can see in the build output that it seems to build my child image and mcuboot configurations, but how can I be sure?

When the build is complete, the dfu_application.zip contains the following even though the mcuboot.conf states "UPDATEABLE_IMAGE=2"

How would I get the cpu_net image into this dfu_application.zip? Am I on the right track?

Here is my project structure:

project_folder
    - cpu_app
        - inc
            - *.h files
        - src
            -*.c files (including main.c)
        - CMakeLists.txt
    - cpu_net
        - inc
            - *.h files
        - src
            -*.c files (including main.c)
        - CMakeLists.txt
        - nrf5340dk_nrf5340_cpu_net.overlay
        - prj.conf
    - CMakeLists.txt
    - nrf5340dk_nrf5340_cpuapp.overlay
    - KConfig
    - prj.conf
    - 

My project_folder/CMakeLists.txt looks like:

#
# Copyright (c) 2020 Nordic Semiconductor
#
# SPDX-License-Identifier: LicenseRef-Nordic-5-Clause
#

cmake_minimum_required(VERSION 3.20.0)

set(ZEPHYR_EXTRA_MODULES ${CMAKE_CURRENT_LIST_DIR})

find_package(Zephyr REQUIRED HINTS $ENV{ZEPHYR_BASE})
project(app)

# NORDIC SDK APP START
FILE(GLOB app_sources cpu_app/src/*.c)

target_sources(app  PRIVATE ${app_sources})
target_include_directories(app PRIVATE cpu_app/inc)

# NORDIC SDK APP END
zephyr_library_include_directories(.)

My project_folder/cpu_app/CMakeLists.txt looks like:

# This check is needed to avoid infinite recursion. This module code will
# be executed for all images in the build, also for the child image being
# added below.
if (CONFIG_INCLUDE_NET_CORE_IMAGE)
  add_child_image(
    NAME cpu_net
    SOURCE_DIR ${CMAKE_CURRENT_LIST_DIR}/../cpu_net
    DOMAIN cpunet
    BOARD ${CONFIG_DOMAIN_CPUNET_BOARD}
    )

    # Add this just below the line "cmake_minimum_required(...)" !!
    if (EXISTS "${CMAKE_CURRENT_SOURCE_DIR}/../mcuboot.conf")
        list(APPEND mcuboot_OVERLAY_CONFIG
            "${CMAKE_CURRENT_SOURCE_DIR}/mcuboot.conf"
        )
    endif()
endif()

My project_folder/cpu_net/CMakeLists.txt looks like:

cmake_minimum_required(VERSION 3.20.0)

find_package(Zephyr REQUIRED HINTS $ENV{ZEPHYR_BASE})
project(cpu_net)

FILE(GLOB app_sources src/*.c)
target_sources(app PRIVATE ${app_sources})
target_include_directories(app PRIVATE inc)

if (CONFIG_SOC_NRF5340_CPUAPP)
  message(FATAL_ERROR "This sample is not supported on the nRF53 application core")
endif()

zephyr_library_include_directories(.)

  • Hi,

    Unfortunately, using a custom image on the network core is not currently supported with multi-image DFU.

    The only workaround I am aware of involves modifying nrf/samples/CMakeLists.txt to add your netcore image, in the same way that netcore images like hci_rpmsg are added.

  • Thank you very much for this information.

    Could you comment on the status of this task? Would it begin development or be in planning for release soon?

    I think I understand what you are mentioning as a workaround, and I will look into that. Correct me here if I am wrong, but perhaps a "workspace" project would be appropriate, so that I can have a specific instance of the SDK to meddle with and not hamper any other projects?

    Notably, I would only mess with the hci_rpmsg sample hidden within the SDK, but please let me know if this approach sounds appropriate.

  • The issue is the order that the build system builds images and how early the build system needs to be aware of the child image. We are in the early stages of supporting sysbuild as a build system, which will hopefully make this easier.

    Yes, if you change the hci_rpmsg sample to fit your needs and keep the modified version at the original location, then I believe you should be able to include it and generate dfu files for it properly.

  • Thanks again for the response. I think for me and my customer's sake, we can proceed with simply adding DFU of the application core only for now. I have that working with the nrfconnect app and sending over a .bin file.

    My next question is going to be slightly off topic, but I have not been able to find a concise answer through my research and DevZone reading: Is encrypted DFU supported in NCS yet? How could I achieve this effect (we will need higher security than just signing the payload) for the nrf5340?

    Let me know if I should start a new thread. I assume you might be able to give me a quick and short answer if it is/not supported.

    Thanks again for your time and support. Much appreciated!

  • Great!

    Yes, starting a new thread for that is best, as it becomes easier to find specific answers for other users.

Related