SDK upgrade guide
nRF Connect SDK 3.2 to nRF Connect SDK 3.3: what needs attention
Migratorisk's knowledge base lists 9 documented changes between nRF Connect SDK 3.2 and nRF Connect SDK 3.3 across 2 releases. 6 of them are rated likely to break code, configuration or builds that use them. Below is each change, what a scan also reviews on this path, and how to see which ones apply to your project.
Find which of these affect your firmware
Migratorisk scans your project on your own computer and reports only the changes your code, configuration and build actually touch. Your source code is not uploaded.
python -m pip install migratorisk migratorisk scan --project ./your-firmware --from ncs-3.2.0 --to ncs-3.3.0 --out report.html
Requires Python 3.12 or newer. Results are free and complete without sign-up; sharing a report with us is optional.
Set up the local scanOr answer a few questions insteadWhere the changes are
What changes between nRF Connect SDK 3.2 and nRF Connect SDK 3.3
Ordered by impact. Each item names the release that introduced it and links to the official source. A change only matters if your project uses what changed; the scan checks that.
TinyCrypt library removed
Zephyr 4.3 removes the TinyCrypt library; every CONFIG_TINYCRYPT* option becomes undefined. PSA Crypto API is the replacement. Covers 12 names.
Kconfig options CONFIG_BT_MESH_USES_MBEDTLS_PSA and 1 more were removed
Kconfigs CONFIG_BT_MESH_USES_MBEDTLS_PSA and CONFIG_BT_MESH_USES_TFM_PSA have been removed. The selection of the PSA Crypto provider is now automatically controlled by Kconfig CONFIG_PSA_CRYPTO. Covers 2 names.
lte_lc modem event enable and disable APIs were removed
NCS 3.3 removes lte_lc_modem_events_enable() and lte_lc_modem_events_disable(); modem events are enabled with CONFIG_LTE_LC_MODEM_EVENTS_MODULE. Covers 2 names.
API MFD_AXP192_AXP2101 was removed
Driver support for AXP2101 has been separated from the AXP192 one. As a consequence the kconfig symbol MFD_AXP192_AXP2101 is removed. MFD_AXP192 is now to be used for AXP192 device while MFD_AXP2101 for the AXP2101 one.
API NRF_ETR was renamed
The nrf_etr driver has been migrated to drivers/debug. As a consequence the related Kconfig symbol was renamed from NRF_ETR to DEBUG_NRF_ETR, along with the rest of the NRF_ETR symbols. Also the driver needs to be explicitly enabled via DEBUG_DRIVER as it is no longer built by default.
Kconfig option CONFIG_MODEM_AT_SHELL_USER_PIPE was renamed
CONFIG_MODEM_AT_SHELL_USER_PIPE has been renamed to CONFIG_MODEM_AT_USER_PIPE.
Partition Manager configuration needs DTS migration review
NCS 3.3 documents Partition Manager deprecation and recommends migrating Nordic projects, except nRF91 Series devices, toward Zephyr devicetree-based partitioning. Covers 2 names.
WPA3 SAE PSA Kconfig names changed
NCS 3.3 removes CONFIG_PSA_WANT_KEY_TYPE_WPA3_SAE_PT and CONFIG_PSA_WANT_ALG_WPA3_SAE in favor of the replacement WPA3 SAE Kconfig options. Covers 2 names.
ExternalNcsVariantProject_Add is deprecated
NCS 3.3 replaces the NCS-specific ExternalNcsVariantProject_Add function with Zephyr's ExternalZephyrVariantProject_Add function.
What a scan of this path also reviews
Beyond the documented changes, Migratorisk reviews these upgrade risks for nRF Connect SDK projects on this path. Each one is reported only when the project shows the trigger.
Custom nRF54/nRF53 board files need NCS 3.3 hardware model review
When it applies: Custom board files and devicetree review targets were found.
Why it matters: NCS 3.2 custom boards should be checked against NCS 3.3 hardware model, chosen-node, pinctrl, and devicetree compatibility guidance before source cleanup.
What to do: Review board directory layout, revision overlays, compatibles, chosen nodes, pinctrl assumptions, and network-core overlays.
Devicetree binding error found in NCS 3.2 to 3.3 build log
When it applies: Build log reports a devicetree binding failure.
Why it matters: Custom board and overlay binding failures should be fixed before interpreting later source API errors.
What to do: Fix custom board and overlay binding errors before treating source API findings as migration failures.
Undefined Kconfig symbol found in NCS 3.2 to 3.3 build log
When it applies: Build log reports an undefined Kconfig symbol after the upgrade attempt.
Why it matters: BLE, MCUboot, mcumgr, board, or nRF54-family symbols can shift dependencies between NCS 3.2 and 3.3.
What to do: Resolve undefined Kconfig symbols before chasing compiler or linker errors later in the log.
MCUboot include or symbol breakage found
When it applies: Build log shows MCUboot-related missing headers or undefined references.
Why it matters: Bootloader include paths, image confirmation, and ownership can still shift between NCS 3.2 and 3.3.
What to do: Resolve sysbuild and Kconfig ownership first, then review the exact MCUboot symbol or include reported in the log.
NCS 3.2 partition layout needs NCS 3.3 review
When it applies: Static partition data may encode OTA, settings, MCUboot, or external-flash assumptions.
Why it matters: NCS 3.2 to 3.3 upgrades can still expose partition ownership or image-size issues before source-level findings are meaningful.
What to do: Compare generated partition reports for MCUboot slots, settings, persistent storage, and external flash after the upgraded sysbuild build.
Signing key path is embedded in NCS 3.2 config
When it applies: A boot signing key path is configured in project files.
Why it matters: Signing configuration and production credentials should be sanitized in public fixtures and revalidated privately before an NCS 3.3 migration.
What to do: Remove private keys and credentials from shared fixtures and verify signing configuration in a private local validation run.
NCS 3.2 sysbuild configuration needs NCS 3.3 review
When it applies: Project has sysbuild, bootloader, or multi-image configuration while targeting NCS 3.3.
Why it matters: NCS 3.2 projects should verify MCUboot, network-core, and application image ownership before treating later build errors as independent migration work.
What to do: Review sysbuild ownership for MCUboot, network core, and application image settings before source cleanup.
West manifest references NCS 3.2 revisions
When it applies: west.yml references old NCS or Zephyr revisions.
Why it matters: Manifest revision drift can make the upgrade build unrepresentative before project-local migration work starts.
What to do: Update the workspace manifest intentionally, then rerun the scan against the upgraded build log.
NCS 3.2 source API review pattern found
When it applies: Source uses BLE, settings, flash map, or bootloader APIs that deserve review after the upgraded build is stable.
Why it matters: This evidence is review-only unless paired with a concrete upgraded build failure.
What to do: Review source API usage after west, sysbuild, partition, board, Kconfig, and devicetree issues are addressed.
NCS 3.2 Bluetooth API usage needs NCS 3.3 review
When it applies: Application source uses Bluetooth APIs that should be checked against the target NCS Bluetooth stack.
Why it matters: Large NCS jumps can expose changed Bluetooth defaults, dependencies, privacy behavior, and GATT/advertising assumptions.
What to do: Review Bluetooth initialization, advertising, scanning, connection, GATT, identity, and privacy usage after the upgraded build is stable.
NCS 3.2 DFU, MCUboot, and mcumgr API usage needs NCS 3.3 review
When it applies: Application source uses DFU, MCUboot, image-management, or SMP APIs.
Why it matters: NCS 3.x migrations often move image ownership into sysbuild and can expose changed bootloader, mcumgr, and DFU dependencies.
What to do: Review image confirmation, upgrade request, mcumgr/SMP transport, FOTA download, DFU target, and download client paths together with partition and sysbuild changes.
NCS 3.2 driver API usage needs NCS 3.3 review
When it applies: Application source uses Zephyr/Nordic driver-facing APIs.
Why it matters: Driver migrations can expose devicetree, pinctrl, power-management, and device readiness assumptions.
What to do: Review device acquisition, readiness checks, pinctrl/devicetree references, and board-specific driver configuration.
NCS 3.2 LTE and modem API usage needs NCS 3.3 review
When it applies: Application source uses Nordic modem, LTE, AT command, modem-info, or location APIs.
Why it matters: nRF91-era migrations can require modem library, LTE link controller, AT command, and location dependency review.
What to do: Review modem library initialization, LTE lifecycle, AT command calls, modem info reads, and GNSS/location flows against the target SDK.
NCS 3.2 network stack API usage needs NCS 3.3 review
When it applies: Application source uses socket, MQTT, CoAP, Thread/OpenThread, Wi-Fi, Nordic cloud, or date/time APIs.
Why it matters: Network migrations can require Kconfig, TLS/security, modem, Thread, Wi-Fi, and cloud dependency review.
What to do: Review network initialization, transport dependencies, TLS/security configuration, cloud flows, and protocol smoke tests.
NCS 3.2 device model and kernel runtime API usage needs NCS 3.3 review
When it applies: Application source uses device model, devicetree macros, partition manager APIs, runtime PM, kernel primitives, or Nordic app framework APIs.
Why it matters: These APIs are sensitive to devicetree, Kconfig, power-management, and generated-header changes across SDK upgrades.
What to do: Review generated devicetree access, device readiness, runtime PM, partition manager symbols, workqueue/thread/timer usage, and app framework event definitions.
NCS 3.2 crypto and TF-M API usage needs NCS 3.3 review
When it applies: Application source uses crypto, PSA, mbedTLS, TF-M, or security-adjacent serialization headers.
Why it matters: Security backend selection and TF-M integration can change dependencies, Kconfig, and runtime behavior across large NCS jumps.
What to do: Review crypto backend configuration, PSA initialization, TF-M calls, key storage, and secure/non-secure boundaries.
NCS 3.2 storage and flash API usage needs NCS 3.3 review
When it applies: Application source uses settings, NVS/ZMS, flash map, flash image, or filesystem APIs.
Why it matters: Storage behavior is tightly coupled to partition manager, MCUboot slots, settings placement, and filesystem dependencies.
What to do: Review persistent storage ownership, flash area IDs, image slots, settings handlers, and filesystem mount paths after partition migration.
First build-log migration error found
When it applies: Build log contains a first high-signal migration error.
Why it matters: Early Kconfig, devicetree, sysbuild, or partition failures often cause later cascading compiler and linker noise.
What to do: Fix this first error before treating later build-log lines as independent migration work.
VelocityCreate
Want us to handle the upgrade?
VelocityCreate can review your assessment, agree on the migration scope, and carry out the firmware changes and agreed verification. Discuss your deadline, hardware, and requirements with an embedded engineer.
Discuss my migrationBook a technical callThe initial discussion is free. Implementation is quoted separately.
Related upgrade paths
Generated from the rule catalog of Migratorisk 0.3.0. This is an automated summary of published SDK changes, not a review of your project, and it does not replace builds and device tests. How the scanner is validated.