Nordic’s nRF Connect SDK 3.0.0 is a significant release with some backwards compatibility breaking changes. If you’re developing products using Nordic’s chipsets and SDK, you should definitely take a look because it can change drastically how you structure your code.
This release has also several improvements and new features as well, so let’s dig into it.
🛜Bluetooth Updates
As always, there’s quite a bit happening on the Bluetooth side
- nRF52H20 Host and Controller are qualified
- Channel sounding Controller and Host will be qualified for the nRF54L Series
- Qualification for multiple LE Audio roles with the following service
- Unicast Client Source
- Broadcast Source (broadcasters/Auracasters).
- Unicast Server Source (microphones)
- Bluetooth Channel Sounding Support
- LE legacy pairing disabled as default for nRF Desktop because it’s not secure
📍 Bluetooth Channel Sounding Support
Althoug nRF Connect SDK 2.9.0 added the Bluetooth Channel Sounding Reflector with Ranging Responder and Initiator samples for the nRF54L Series devices (which supports Bluetooth Channel Sounding), the support was only experimental and things like the ranging algorithms were giving limited accuracy. It wasn’t showing Channel Sounding’s full potential.
The new nRF Connect SDK 3.0.0 officially adds Channel Sounding and Nordic will be qualifying it so that developers can release products. We’ve yet to finish all our testing with Nordic’s Bluetooth Channel Sounding on the nRF54 but we hope to have some results soon.
From the results it seems there’s improvements but there’s still more work to be done. Still, you’re best off using the latest and greatest.
🪓 Hardware Model v1 Deprecated
The nRF Connect SDK Hardware Model v1 (HWMv1) is the original system used by Nordic Semiconductor to define and manage hardware configurations in the nRF Connect SDK. It was the default option in SDK versions before 2.7.0.
In HWMv1, hardware definitions are structured hierarchically and are primarily organized based on the architecture of the system. This model includes the following layers:
- Board: Specific development kits or custom hardware configurations.
- SoC (System on Chip): The exact chip used on the board.
- SoC Family: A broader classification grouping similar SoCs.
- SoC Series: A more specific grouping within a family.
- CPU Core: The processor core used in the SoC.
- Architecture: The instruction set architecture, such as ARM.
This structure allowed developers to define and manage hardware-specific configurations using Devicetree files and Kconfig options, facilitating the development of applications tailored to specific hardware setups.
But as the complexity of hardware designs increased, especially with the introduction of multi-core and multi-SoC systems, the limitations of HWMv1 became apparent. To address these challenges, Nordic introduced Hardware Model v2 (HWMv2) in nRF Connect SDK version 2.7.0. HWMv2 offers a more flexible and extensible approach to hardware definition, accommodating modern hardware architectures more effectively. Notable improvements in HWMv2 include:
- Vendor-Based Organization: Boards are now organized under their respective vendors rather than architectures, allowing for better support of boards with multiple architectures.
- YAML-Based Descriptions: HWMv2 uses YAML files for defining hardware components, enhancing readability and maintainability.
- Improved Multi-Target Support: The new model better handles boards with multiple targets, like those with separate application and network cores.
🧩 Multi-Image builds Deprecated
Multi-image builds (also called parent-child images) are the original way of building firmware for nRF5x devices under the nRF Connect SDK and they’ve now been completely replaced with Sysbuild.
Sysbuild is a build system designed to handle multiple firmware images within a single project. It replaces the previous multi-image build system, offering a more scalable and maintainable approach. It’s a new build system wrapper that allows you to define and manage multiple firmware images under a single top-level CMake project. Instead of managing child images individually (e.g., MCUboot, Application, Network Core firmware), Sysbuild automates the orchestration between them.
In short:
- One command builds everything.
- One configuration controls everything.
- One merged output makes flashing easy.
Sysbuild acts like a “build meta-project” that ties together all the child images into a unified structure. We will be doing a complete tutorial on how to take advantage of everything Sysbuild has to offer.
🖥️ nRF Command Line Tool Deprecated
The nRF Command Line Tools is now deprecated and is replaced by the nRF Util utility. If you’ve used the nRF Command Line tools you’ll miss them, but the nRF Util overall is the swiss knife of utilities for nRF5x devices and has everything you need to develop.
🧰 Hardware and Platform Support
The SDK expands support for various hardware components:
- nRF54L Series: Support for HMAC SHA-256 with a 128-bit key type to the Key Management Unit (KMU), enhancing cryptographic operations.
- Front-End Modules: Introduced support for nRF2220 and nRF21540 Front-End Modules, facilitating extended range and power control.
- nPM2100 PMIC: New documentation and support for the nPM2100 Power Management IC, aiding in efficient power management designs.
Added Support for nPM2100 PMIC. if you’re using Primary batteries, then the nPM2100 is a great add on to your design because it’s small and contains a lot of capabilities you’d typically have to put together yourself. nRF SDK 3.0.0 adds
🔐 Security Enhancements
nRF Connect SDK v3.0.0 brings notable security improvements:
- CRACEN Library Updates: Inclusion of HKDF-Expand and HKDF-Extract functions, along with Ed25519ph (HashEdDSA) support, enhancing cryptographic capabilities.
- Oberon PSA Core v1.3.4: Upgraded to support PSA static key slots, key wrapping (NIST-SP-800-38F), and WPA3-SAE protocols, bolstering secure communications.
- Trusted Firmware-M (TF-M) Documentation: New pages detailing TF-M architecture and PSA Certified Security Framework, aiding developers in implementing robust security measures.
- Experimental Support for ECIES x25519 encryption using MCUboot
🛠️ Build System
nRF Connect SDK v3.0.0 brings notable security improvements:
- west flash: The
west flashcommand now uses the nRFUtil instead of the nrfjprog - Erase Flag: Prior to 3.0.0, using the erase flag would be inconsistent depending on the utility used. nrfjprog would erase only sectors used, while nrfutil would erase the whole flash. This resulted in confusion sometimes and we’ve even had to force an erase when the chip wasn’t fully erased and we found some strange behaviors. Now it will consistently always erase the complete chip regardless.
- Trusted Firmware-M (TF-M) Documentation: There’s new pages detailing TF-M architecture and PSA Certified Security Framework, aiding developers in implementing robust security measures.
📶Matter Support
For those developers working on products with the Matter protocol, there’s good news
- Matter 1.4.1 support added
- Certification of Matter Commissioning using an NFC Tag is now available
- Matter: Manufacturer-specific sample has been added along with documentation and a PC tool to allow creating manufacturer specific clusters
Other Changes
- Zigbee R22, Amazon Sidewalk, and Asset tracker v2 application have been removed from the SDK and are now available as part of the nRF Connect SDK Add-on.
- Asset Tracker v2 application has been replaced by the Asset Tracker Template as part of the nRF Connect SDK Add-on
