Build and configuration system

The nRF Connect SDK build and configuration system is based on the one from Zephyr, with some additions.

Zephyr’s build and configuration system

Zephyr’s build and configuration system uses the following building blocks as a foundation:

• CMake, the cross-platform build system generator

• Kconfig, a powerful configuration system also used in the Linux kernel

• Devicetree, a hardware description language that is used to describe the hardware that the nRF Connect SDK is to run on

Since the build and configuration system used by the nRF Connect SDK comes from Zephyr, references to the original Zephyr documentation are provided here in order to avoid duplication. See the following links for information about the different building blocks mentioned above:

• Application Development is a complete guide to application development with Zephyr, including the build and configuration system.

• Build System (CMake) describes in-depth the usage of CMake for Zephyr-based applications.

• Kconfig Configuration contains a guide for Kconfig usage in applications.

• Set devicetree overlays explains how to use devicetree and its overlays to customize an application’s devicetree.

• Board Porting Guide is a complete guide to porting Zephyr to your own board.

nRF Connect SDK additions

The nRF Connect SDK adds some functionality on top of the Zephyr build and configuration system. Those additions are automatically included into the Zephyr build system using a Zephyr Build Configuration CMake package.

You must be aware of these additions when you start writing your own applications based on this SDK.

• The Kconfig option CONFIG_WARN_EXPERIMENTAL is enabled by default. It gives warnings at CMake configure time if any experimental feature is enabled.

  For example, when building a sample that enables CONFIG_BT_EXT_ADV, the following warning is printed at CMake configure time:

  warning: Experimental symbol BT_EXT_ADV is enabled.
  

• The nRF Connect SDK provides an additional boilerplate.cmake that is automatically included when using the Zephyr CMake package in the CMakeLists.txt file of your application:

  find_package(Zephyr HINTS $ENV{ZEPHYR_BASE})
  

• The nRF Connect SDK allows you to create custom build type files instead of using a single prj.conf file.

• The nRF Connect SDK build system extends Zephyr’s with support for multi-image builds. You can find out more about these in the Multi-image builds section.

• The nRF Connect SDK adds a partition manager, responsible for partitioning the available flash memory.

• The nRF Connect SDK build system generates zip files containing binary images and a manifest for use with nRF Cloud FOTA.

Building FOTA images

The nRF Connect SDK build system places output images in the <build folder>/zephyr folder.

If CONFIG_BOOTLOADER_MCUBOOT is set, the build system creates the dfu_application.zip file containing files app_update.bin and manifest.json. If you have also set the options CONFIG_IMG_MANAGER and CONFIG_MCUBOOT_IMG_MANAGER, the application will be able to process FOTA updates. If you have set the options CONFIG_SECURE_BOOT and CONFIG_BUILD_S1_VARIANT, a similar file dfu_mcuboot.zip will also be created. You can use this file to perform FOTA updates of MCUboot itself.

The app_update.bin file is a signed version of your application. The signature matches to what MCUboot expects and allows this file to be used as an update. The build system creates a manifest.json file using information in the zephyr.meta output file. This includes the Zephyr and nRF Connect SDK git hashes for the commits used to build the application. If your working tree contains uncommitted changes, the build system adds the suffix -dirty to the relevant version field.