nRF Desktop: Memory layout

You must define the memory layout as a part of the application configuration for a given board. The set of required partitions differs depending on the configuration:

  • There must be at least one partition where the code is stored.

  • There must be one partition for storing Settings.

  • If the bootloader is enabled, it adds more partitions to the set.

  • When using an SoC with multiple cores, the firmware for additional cores adds more partitions to the set. For example, the network core of the nRF53 SoC uses the IPC radio firmware image, which allows to use the core for Bluetooth LE communication.

Important

Before updating the firmware, make sure that the data stored in the settings partition is compatible with the new firmware. If it is incompatible, erase the settings area before using the new firmware.

The memory layout is defined through one of the following methods:

By default, a Zephyr-based application defines the memory layout in the DTS. If enabled, the Partition Manager defines a new memory layout that is used instead of the memory layout defined in the DTS. You can use the SB_CONFIG_PARTITION_MANAGER sysbuild Kconfig option to enable Partition Manager in the current build.

Note

Starting from the nRF Connect SDK v3.4.0, all nRF Desktop application configurations are migrated from Partition Manager to DTS memory layout because of the Partition Manager deprecation. The Partition Manager should not be used for new products.

Memory layout and bootloaders

The used memory layout depends on selected bootloader and DFU method:

  • For the background firmware upgrade, you must define the secondary image partition. This is because the update image is stored on the secondary image partition while the device is running firmware from the primary partition. The feature may be problematic for devices with smaller non-volatile memory size, because the size of the required internal non-volatile memory is essentially doubled. Devices with smaller non-volatile memory size can use either USB serial recovery or the MCUboot bootloader in swap mode with the secondary image partition located on an external non-volatile memory. In this mode, the MCUboot moves the image data from the secondary image partition on the external non-volatile memory to the primary image partition before booting the new firmware.

  • When you use USB serial recovery, you do not need the secondary image partition. The firmware image is overwritten by the bootloader.

For more information about available bootloaders and their modes, see the nRF Desktop: Bootloader and Device Firmware Update documentation.

Memory layout in DTS

If you rely on a non-volatile memory layout described in DTS files, define the partitions child node under the DTS node that represents the non-volatile memory. For example, the nRF52 Series devices use internal non-volatile flash memory represented by the &flash0 DTS node and the application core of nRF54L Series devices uses internal non-volatile RRAM memory represented by the &cpuapp_rram DTS node. Make sure to also update the DTS chosen nodes, which represent the code partition (zephyr,code-partition) and flash (zephyr,flash), if needed.

If you wish to change the default memory layout for the board without editing the board-specific files, use the DTS overlay file. nRF Desktop application configurations define the non-volatile memory layout in the memory_map.dtsi files (for example, memory_map.dtsi or memory_map_release.dtsi). These files are placed in the project’s board configuration directory and are included by the DTS overlay file of the given build type (for example, app.overlay or app_release.overlay). The DTS configuration is defined separately for every sysbuild image. The new memory map needs to be included in all built sysbuild images that use the memory map (for example bootloader). The set of partitions that needs to be specified depends on the selected bootloader (and its mode), too. See the nRF Desktop board configuration directories for examples of the DTS-based memory layout definitions. For more details on the application configurations, see the nRF Desktop: Board configuration documentation.

Important

By default, Zephyr does not use the code partition defined in the DTS files. It is only used if the CONFIG_USE_DT_CODE_PARTITION Kconfig option is enabled. If this option is disabled, the code is loaded at the offset defined by the CONFIG_FLASH_LOAD_OFFSET Kconfig option. In that case, the code spawns for CONFIG_FLASH_LOAD_SIZE (or for the whole remaining chosen zephyr,flash memory if the load size is set to 0). The settings memory partition definition is still used by the firmware even if the CONFIG_USE_DT_CODE_PARTITION Kconfig option is disabled. The nRF Desktop application explicitly enables the CONFIG_USE_DT_CODE_PARTITION Kconfig option to use the memory layout defined in DTS.

For more information about how to configure the non-volatile memory layout in the DTS files, see Flash map.

External flash configuration

Devices with smaller non-volatile memory size can use MCUboot bootloader in swap mode with secondary image partition located on an external non-volatile memory. For an example of the nRF Desktop application configuration that uses an external flash, see the mcuboot_qspi configuration of the nRF52840 DK. This configuration uses the MX25R64 external flash that is part of the development kit.

The memory map is defined in DTS (see memory_map_mcuboot_qspi.dtsi), with the slot1_partition placed under the mx25r64 node.

Memory layout in Partition Manager

Note

The Partition Manager is a component in the nRF Connect SDK and is responsible for handling the memory partitioning at build time.

This functionality is in the process of being deprecated and replaced by Zephyr’s default devicetree-based memory partitioning. It is recommended that all new designs using Nordic devices are to be built with DTS instead of Partition Manager. Partition Manager will be removed from the nRF Connect SDK by the end of 2026 from the main branch.

For more information on how to configure partitions using DTS and how to migrate your existing configuration to DTS, see the following pages:

When the SB_CONFIG_PARTITION_MANAGER sysbuild Kconfig option is enabled, the nRF Desktop application uses the Partition Manager for the memory layout configuration. The nRF Desktop configurations use static configurations of partitions to ensure that the partition layout does not change between builds.

Add the pm_static_$FILE_SUFFIX.yml file to the project’s board configuration directory to define the static Partition Manager configuration for given board and build type. For example, to define the static partition layout for the nrf52840dk/nrf52840 board and release build type, you would need to add the pm_static_release.yml file into the applications/nrf_desktop/configuration/nrf52840dk_nrf52840 directory.

For an example of configuration, see the static partition maps defined for the existing configuration that uses a given DFU method. For more information about how to configure the non-volatile memory layout using the Partition Manager, see Partition Manager.

External flash configuration

Devices with smaller non-volatile memory size can use MCUboot bootloader in swap mode with secondary image partition located on an external non-volatile memory. For an example of the nRF Desktop application configuration that uses an external flash, see the mcuboot_qspi configuration of the nRF52840 DK. This configuration uses the MX25R64 external flash that is part of the development kit.

Up to the nRF Connect SDK v3.3.0 release, Partition Manager was used to control the memory partition layout for this application configuration. The SB_CONFIG_PM_EXTERNAL_FLASH_MCUBOOT_SECONDARY sysbuild Kconfig option was used next to the proper static Partition Manager configuration to place the MCUboot secondary image slot in external flash. For detailed information, see the Partition Manager documentation.