Multi-Image DFU project structure

[Robert de Brum]

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(.)

[Øivind]

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.

[Robert de Brum]

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.

[Øivind]

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.

[Robert de Brum]

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!

[Øivind]

Great!

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

[Robert de Brum]

I just entered a new ticket here:  Encrypted DFU nrf5340 in NCS with case ID 301424.

Back on the same topic of FOTA DFU for both the network and application core:

I am able to send over a DFU binary, and update the application core via BLE FOTA for my custom project that contains source code for both the application and network core. However, this of course does not update the network core.

Is it possible to generate and send over the binary package required to update just the network core? Essentially, my customer would be satisfied with performing a DFU of the network core and application core separately with two different binaries instead of simultaneously.

[Robert de Brum]

Could I get an update on this?

[Øivind]

Hi, sorry for not getting back to you earlier

It is possible to send over the binary for each core separately, app_update.bin for the application core and net_core_app_update.bin for the network core.
However, this still requires an MCUboot build that supports updating both cores, which is the core issue. As I said earlier, the issue is in the build system, not in MCUboot's capabilities.

You mentioned earlier that you could perhaps modify hci_rpmsg to fit your needs, and if that is sufficient then you should not encounter any issues with simultaneous or non-simultaneous updates of the cores.