Migration notes for nRF Connect SDK v3.4.0 (Working draft)

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.

Samples and applications 

This section describes the changes related to samples and applications.

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 language support and the 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;
};
```

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 with this notice. 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 will be emitted when these values are referenced due to the Kconfig define generation process.

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.

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.