If you are having issues with the exercises, please create a ticket on DevZone:
Click or drag files to this area to upload. You can upload up to 2 files.

Devicetree overlays, CMake, and multi-image builds

Devicetree overlays

In lesson 2, we covered the devicetree, a hierarchical data structure that describes hardware through nodes with belonging properties. It is not recommended to modify the devicetree directly, so instead we use devicetree overlays to do this. The overlay only needs to include the node and property it wants to modify.

The overlay file shown above will set node spi1 to have the status okay, essentially enabling this node. Then it is changing the pin configuration for the SPIM_MOSI line to pin 25 by changing the appropriate sub-nodes and properties in the &pinctrl node. Note that you must change the pin configuration for both the default and sleep states.

If an overlay file sets a node’s property to a value it already has, the node will just remain unchanged.

One easy way to create an overlay file is to create a file with the name of the board and the extension .overlay and place it directly in the application root directory. The build system will automatically search for this file type and include it if it finds one.

However, there are several other ways to include overlay files. See Set devicetree overlays for a list of ways to include a devicetree overlay in your application.


Overlays are also DTS files, the .overlay extension is just a convention that makes their purpose clear. 


In the nRF Connect SDK, all applications are CMake projects. This means that the application controls the configuration and build process of itself, Zephyr, and all sourced libraries. The file CMakeLists.txt is the main CMake project file and the source of this build process configuration.

We will take a closer look at some of the functions in the exercise.

Multi-Image Builds

Now that we have covered all the different elements of an application in the nRF Connect SDK, it’s time to talk about images and multi-image builds. The firmware running on a device can consist of one application or image, or it can consist of multiple images, making it a multi-image build.

Multi-image builds consist of a parent image and one or more child images, where the child image is included by the parent image.

Multi-image builds are used in the following cases:

  • Applications that have DFU enabled (serial, USB-CDC, BLE, etc.)
  • Multi-core or multi-partition targets (nRF53 and nRF9160)

In these cases, the creation of the multi-image build happens by default so it isn’t something a developer needs to take care of. More details on Multi-Image builds can be found here.

Register an account
Already have an account? Log in
(All fields are required unless specified optional)

  • 8 or more characters
  • Upper and lower case letters
  • At least one number or special character

Forgot your password?
Enter the email associated with your account, and we will send you a link to reset your password.