Migration notes for nRF Connect SDK v3.4.0

This document describes the changes required or recommended when migrating your application from nRF Connect SDK v3.3.0 to nRF Connect SDK v3.4.0.

Required changes

The following changes are mandatory to make your application work in the same way as in previous releases.

Partition Manager deprecation

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

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

Samples, tests, and applications that previously relied on Partition Manager must now provide devicetree overlays that define the required flash and RAM partitions. For cellular use cases, you can reuse the partition layouts from nrf/dts/samples/cellular/*.dtsi by including the appropriate file in your board overlay.

For more information on how to configure partitions using DTS and how to migrate your existing configuration to DTS, see the Migrating partition configuration from Partition Manager to devicetree (DTS) page.

Security

Removal of legacy PSA Crypto API

The Mbed TLS module was updated to v4.1.0 (from v3.6.6).

This change removed support for legacy, deprecated mbedcrypto APIs and related tests (prefixed with mbedtls_). As a consequence, the nRF Security subsystem was updated: Kconfig options related to Mbed TLS were rearranged and the outdated Kconfig options were removed. The subsystem now uses the Mbed TLS integration from Zephyr as-is CONFIG_MBEDTLS_BUILTIN) while replacing upstream TF-PSA-Crypto with Oberon PSA Crypto (CONFIG_TF_PSA_CRYPTO_CUSTOM).

From this update onwards:

• Configure cryptographic features using Configuring PSA Crypto API and Supported cryptographic operations in the nRF Connect SDK instead of the legacy implementation.

• Enable CONFIG_MBEDTLS only if you use TLS or X.509.

• For cryptographic operations, enable only CONFIG_PSA_CRYPTO.

For an overview of the changes brought by this update in Mbed TLS and Zephyr, see the following pages:

• The Mbed TLS sections of the Zephyr v4.4 release notes and migration guide.

• Official Mbed TLS’ TF-PSA-Crypto migration guide and Transitioning to the PSA API document.

• The release notes from upstream Mbed TLS:

  • Mbed TLS 4.0.0 release notes

  • TF-PSA-Crypto 1.0.0 release notes

  • Mbed TLS 4.1.0 release notes

  • TF-PSA-Crypto 1.1.0 release notes

Build and configuration system

HAL global define deprecation

Global HAL defines are deprecated. Do not reference the following global defines in code:

• NRF51

• NRF51422_XXAA

• NRF51422_XXAB

• NRF51422_XXAC

• NRF52805_XXAA

• NRF52810_XXAA

• NRF52811_XXAA

• NRF52820_XXAA

• NRF52832_XXAA

• NRF52833_XXAA

• NRF52840_XXAA

• NRF5340_XXAA_APPLICATION

• NRF5340_XXAA_NETWORK

• NRF54H20_XXAA

• NRF54L05_XXAA

• DEVELOP_IN_NRF54L15

• NRF54L10_XXAA

• NRF54L15_XXAA

• DEVELOP_IN_NRF54LM20B

• NRF54LM20A_XXAA

• NRF7120_ENGA_XXAA

• NRF54LM20B_XXAA

• NRF_FLPR

• NRF9120_XXAA

• NRF9160_XXAA

• NRF_APPLICATION

• NRF_RADIOCORE

• NRF_PPR

• ENABLE_APPROTECT

• ENABLE_APPROTECT_USER_HANDLING

• ENABLE_AUTHENTICATED_APPROTECT

• ENABLE_SECURE_APPROTECT

• ENABLE_SECUREAPPROTECT

• ENABLE_SECURE_APPROTECT_USER_HANDLING

• ENABLE_AUTHENTICATED_SECUREAPPROTECT

• NRF_SKIP_FICR_NS_COPY_TO_RAM

• NRF_CONFIG_CPU_FREQ_MHZ

• NRF_SKIP_CLOCK_CONFIGURATION

• NRF_DISABLE_FICR_TRIMCNF

• NRF_SKIP_TAMPC_SETUP

• NRF_SKIP_GLITCHDETECTOR_DISABLE

• NRF54L_CONFIGURATION_56_ENABLE

Use the corresponding Kconfig symbols instead.

Samples and applications

This section describes the changes related to samples and applications.

nRF Audio (formerly nRF5340 Audio)

• The buildprog.py script no longer supports the -u (user name) option. Use the -cn (custom name) option instead. The custom name is now used for both unicast and broadcast. Changing this parameter requires a pristine build. The option is intended as a convenience argument; set names through configuration options for persistent configuration.

Matter

• The Partition Manager has been deprecated, removed from the Matter samples and applications and replaced by Zephyr’s default devicetree-based memory partitioning. The base .dtsi files for all supported SoCs have been created in the nrf/dts/samples/matter directory. The files from the nrf/dts/samples/matter directory are used by default in all Matter samples and applications. You can also reuse them as a base for your own custom partitioning.

  To reuse the base .dtsi files for your own custom partitioning, find the appropriate base .dtsi file for your SoC and include it in your .overlay board file. For example, to reuse the base file for the nrf54lm20dk/nrf54lm20b/cpuapp board target, add the following line to your sample/boards/nrf54lm20dk_nrf54lm20b_cpuapp.overlay board file:

  #include "<samples/matter/nrf54lm20_cpuapp_partitions.dtsi>"
  

  After that, once the base is ready, you can modify partitions by using the nRF Connect for VS Code with its Devicetree Visual Editor, or manually edit the .overlay file.

  For more information on how to configure partitions using DTS and how to migrate your existing configuration to DTS, see the Migrating partition configuration from Partition Manager to devicetree (DTS) page.

• The Matter: Window covering sample now uses the Thread Sleepy End Device (SED) device type by default. You can enable the Thread Synchronized Sleepy End Device (SSED) device type as an optional feature. To enable the Thread SSED support, add the -DEXTRA_CONF_FILE=ssed.conf extra argument to the build command.

Libraries

This section describes the changes related to libraries.

• Location library:

  • The library now always uses the chosen zephyr,wifi node to find the used Wi-Fi device. If your application uses the deprecated ncs,location-wifi node, you need to change it to use the zephyr,wifi node instead:

    chosen {
            zephyr,wifi = &mywifi;
    };
    

Wi-Fi®

• The Wi-Fi Enterprise snippet has changed. Use the nRF Connect SDK nordic-wifi-enterprise snippet instead of Zephyr’s wifi-enterprise snippet for Wi-Fi Enterprise builds. The nRF Connect SDK snippet is available in snippets/nordic-wifi-enterprise.

Recommended changes

The following changes are recommended for your application to work optimally after the migration.

Build and configuration system

• The Kconfig options CONFIG_SRAM_SIZE and CONFIG_SRAM_BASE_ADDRESS have been deprecated. Use the devicetree zephyr.sram chosen node to specify which RAM node is used. If you adjust either option manually, CONFIG_SRAM_DEPRECATED_KCONFIG_SET is set to indicate the deprecation. However, applications will continue to build and work, and a deprecation notice will be shown. For the majority of cases, you should not change these values as they default to the values of the zephyr,sram chosen node. If the code references these Kconfig options, you should update them. No deprecation warning is emitted when these values are referenced, because of how Kconfig defines are generated.

  Note

  This is listed in the recommended changes for this nRF Connect SDK release. In the next nRF Connect SDK release, this will be a required change.

Nordic SoC platform symbols (Haltium / Lumos)

The internal Haltium and Lumos platform names have been removed from the Nordic SoC integration in favor of the explicit Zephyr SOC_SERIES_* symbols. Old symbols, headers, and macros are kept as deprecated aliases for one release cycle and emit a deprecation warning at build time. Update your application as follows:

• Kconfig options:

  • Replace CONFIG_NRF_PLATFORM_HALTIUM with CONFIG_SOC_SERIES_NRF54H or CONFIG_SOC_SERIES_NRF92 (whichever applies).

  • Replace CONFIG_NRF_PLATFORM_LUMOS with CONFIG_SOC_SERIES_NRF54L or CONFIG_SOC_SERIES_NRF71 (whichever applies).

  • Replace SB_CONFIG_NRF_HALTIUM_GENERATE_UICR with SB_CONFIG_NRF_GENERATE_UICR in your sysbuild.conf file.

• C headers (zephyr/soc/nordic/common/):

  • Replace #include <haltium_power.h> with #include <soc_power.h>.

  • Replace #include <haltium_pm_s2ram.h> with #include <soc_pm_s2ram.h>.

• C macros:

  • Replace HALTIUM_PLATFORM_PSA_KEY_ID(...) with NRF_PLATFORM_PSA_KEY_ID(...) from include/psa/nrf_platform_key_ids.h.

The following table summarizes the renames:

Haltium / Lumos platform symbol renames

Old name	New name	Type
CONFIG_NRF_PLATFORM_HALTIUM	CONFIG_SOC_SERIES_NRF54H or CONFIG_SOC_SERIES_NRF92	Kconfig
CONFIG_NRF_PLATFORM_LUMOS	CONFIG_SOC_SERIES_NRF54L or CONFIG_SOC_SERIES_NRF71	Kconfig
SB_CONFIG_NRF_HALTIUM_GENERATE_UICR	SB_CONFIG_NRF_GENERATE_UICR	Sysbuild Kconfig
<haltium_power.h>	<soc_power.h>	Header
<haltium_pm_s2ram.h>	<soc_pm_s2ram.h>	Header
HALTIUM_PLATFORM_PSA_KEY_ID()	NRF_PLATFORM_PSA_KEY_ID()	Macro

Note

The MDK-defined HALTIUM_XXAA and LUMOS_XXAA preprocessor symbols are managed by the MDK release schedule and are not affected by this migration. Code that needs to distinguish hardware should use the corresponding NRF54H_SERIES, NRF92_SERIES, NRF54L_SERIES, or NRF7120_ENGA_XXAA defines instead.

Samples and applications

This section describes the changes related to samples and applications.

No changes since the latest nRF Connect SDK release.

Libraries

This section describes the changes related to libraries.

Google Fast Pair

For applications and samples using the Google Fast Pair Service (GFPS) library:

• The devicetree (DTS) partition overlays of the Fast Pair samples and Fast Pair-enabled board targets have been migrated from the legacy fixed-partitions compatible string to the new zephyr,mapped-partition compatible string introduced in Zephyr. The new layout matches the output of the Partition Manager-to-DTS helper script (scripts/pm_to_dts.py) and aligns the Fast Pair sample overlays with the partition binding convention adopted by the rest of the Zephyr SoC devicetree.

  If your application uses a Fast Pair DTS partition overlay derived from earlier nRF Connect SDK releases, update each <board_target>.overlay file as follows:

  • On the partitions grouping node, replace the compatible = "fixed-partitions"; property with an empty ranges; property.

  • On every child partition node (for example, boot_partition, slot0_partition, slot1_partition, bt_fast_pair_partition, and storage_partition), add the compatible = "zephyr,mapped-partition"; property.

  For example, replace the following overlay snippet:

  partitions {
      compatible = "fixed-partitions";
      #address-cells = <1>;
      #size-cells = <1>;
  
      slot0_partition: partition@0 {
          label = "image-0";
          reg = <0x0 DT_SIZE_K(996)>;
      };
  };
  

  With the following:

  partitions {
      ranges;
      #address-cells = <1>;
      #size-cells = <1>;
  
      slot0_partition: partition@0 {
          compatible = "zephyr,mapped-partition";
          label = "image-0";
          reg = <0x0 DT_SIZE_K(996)>;
      };
  };
  

  Refer to the partition overlays under the nrf/samples/bluetooth/fast_pair/locator_tag/ and nrf/samples/bluetooth/fast_pair/input_device/ sample directories for complete examples of the updated layout.

  Important

  This migration is mandatory on nRF53 Series board targets. Recent Zephyr updates added a ranges translation to the flash1 SoC node (network core flash), so DT_REG_ADDR() on partition nodes now returns their bus address rather than their in-flash offset. With the legacy fixed-partitions compatible, the Zephyr linker still uses CONFIG_FLASH_BASE_ADDRESS + CONFIG_FLASH_LOAD_OFFSET to place the network core code partition, which double-counts the flash1 base. As a result, the network core image is linked at an address outside the valid flash range and nrfutil rejects programming with the following message:

  Device error: Address range 0x02008800..0x020262ac is outside the memory ranges defined for programming through the Network core (Generic)
  

  Switching to zephyr,mapped-partition makes the linker derive the network core code partition’s load address directly from DT_REG_ADDR(zephyr_code_partition), which yields the correct bus address and avoids the double-counting. On the application core, where flash0 uses identity ranges, both compatibles produce the same addresses, but updating the overlays is still recommended for consistency.

nRF Cloud library

• The default value of the CONFIG_NRF_CLOUD_CLIENT_ID_SRC choice has changed from CONFIG_NRF_CLOUD_CLIENT_ID_SRC_IMEI to the device UUID. On an nRF9160 device, the new default is CONFIG_NRF_CLOUD_CLIENT_ID_SRC_INTERNAL_UUID. On the nRF91x1 and future SoCs, the new default is CONFIG_NRF_CLOUD_CLIENT_ID_SRC_MDM_DEVICE_UUID.

  If your application relied on the previous IMEI-based default without setting it explicitly in the prj.conf file, the device will connect to nRF Cloud with a different client ID after the upgrade and appear as a new, unprovisioned device. To preserve the previous behavior, add the following line to your prj.conf file:

  CONFIG_NRF_CLOUD_CLIENT_ID_SRC_IMEI=y
  

  The CONFIG_NRF_CLOUD_CLIENT_ID_SRC_IMEI and CONFIG_NRF_CLOUD_CLIENT_ID_SRC_HW_ID Kconfig options are deprecated but kept functional for fleet operators with IMEI-provisioned devices already in the field. New applications should use the UUID default to match the device ID that the nRF Cloud provisioning tools generate.