Multi-image buildsΒΆ

In many cases, the firmware that is programmed to a device consists of not only one application, but several separate images, where one of the images (the parent image) requires one or more other images (the child images) to be present. The most common use case for builds consisting of multiple images is an application that requires a bootloader to be present.

In the context of nRF Connect SDK, multiple images are required in the following scenarios:

nRF9160 SPU configuration

The nRF9160 SiP application MCU is divided into a secure and a non-secure domain. The code in the secure domain can configure the System Protection Unit (SPU) to allow non-secure access to the CPU resources that are required by the application, and then jump to the code in the non-secure domain. Therefore, the nRF9160 samples (the parent image) require the nRF9160: Secure Partition Manager (the child image) to be programmed in addition to the actual application.

See nRF9160-PCA10090 and Working with nRF9160 samples for more information.

MCUboot bootloader

The MCUboot bootloader establishes a root of trust by verifying the next step in the boot sequence. This first-stage bootloader is immutable, which means it must never be updated or deleted. However, it allows to update the application, and therefore MCUboot and the application must be located in different images. In this scenario, the application is the parent image and MCUboot is the child image.

See MCUboot for more information. The MCUboot bootloader is used in the nRF9160: HTTP application update sample.

In such cases where the firmware consists of several images, you can build each of the images separately and program it to the correct place in flash.

Alternatively, you can build the related images as one solution, starting from the parent image. This is referred to as multi-image build, and it is the default way how the nRF Connect SDK samples are set up. When building the parent image, you can configure if a child image should automatically be built and included in the parent image (the default), if a prebuilt HEX file should be included instead of the child image, or if the child image should be ignored. If you are creating your own application, see Building and Configuring multiple images in Application Development for more information about how to turn your application into a parent image that requires specific child images.

In a multi-image build, all images must be placed in memory so that they do not overlap. The flash start address for each image must be specified by, for example, CONFIG_FLASH_LOAD_OFFSET. Hardcoding the image locations like this works fine for simple use cases like a bootloader that prepares a device, where there are no further requirements on where in memory each image must be placed. However, more advanced use cases require a memory layout where images are located in a specific order relative to one another. The nRF Connect SDK provides a Python tool that allows to specify this kind of relative placement, or even a static placement based on start addresses and sizes for the different images. See Partition Manager for more information about how to set up your partitions and configure your build system.