CREATING NEW DESIGNS WITH nRF CONNECT SDK (NCS)

Nordic Semiconductor has supported their silicon offerings for over 10 years with the nRF5 SDK (Software Development Kit). This SDK is still widely in use for chip variants up through the nRF52 series. The new nRF Connect SDK is recommended by Nordic for all new designs based on the nRF52 and later and is required for nRF3 and later.

This article describes the nRF Connect SDK (NCS) environment and is aimed at developers who are interested in working with new firmware designs based on Nordic RF Chips.

The nRF Connect SDK is a software development ecosystem provided by Nordic Semiconductor for the nRF52, nRF53 and nRF91 series silicon. It is a completely different environment from the previous nRF5 SDK.

It offers developers an extensible framework for building size-optimized software for memory-constrained devices as well as more complex and powerful devices and applications. Significantly, it integrates the open source, highly configurable Zephyr RTOS. Nordic has integrated a full spectrum of samples, protocols, libraries, and hardware support for all of the silicon offerings mentioned above and the related hardware developer kits.

It uses source code management with Git, and is publicly hosted on GitHub. Although you can use the NCS environment with any IDE, Nordic makes available a free nRF Connect for VS Code IDE extension.

Nordic is consistently adding new features to the NCS, and runs continuous integration tests to ensure robust and secure production quality code.

You can find the landing page for the nRF Connect SDK on the Nordic Semiconductor website here.

Topics in this article include:

• Differences between the nRF5 SDK and the NCS
• NCS Components
• Updated Desktop Apps
• IDE and Toolchain
• Using the NCS with Docker
• Learning the nRF Connect SDK

NCS vs nRF5 SDK

The nRF5 SDK is in maintenance mode​ and is not recommended for new designs​. In other words, if you want to take advantage of a more complete application development environment, use the latest versions of various IoT protocols, develop applications using out-of-the-box AI and Machine Learning and many other added technologies, you’ll want to migrate to the NCS.

The NCS is a complete development ecosystem based around the Zephyr RTOS, whereas the nRF5 SDK requires adding a cross-compiler, does not include an RTOS or TCP/IP stack or unit testing libraries, and requires developers to choose among separate versions of the SDK depending on protocol support needed for each design, i.e., Bluetooth mesh, HomeKit, Thread or Zigbee.

The NCS supports most (if not all) of the nRF5 examples, including support for proprietary radio libraries such as ESB, Gazell, gzp as well as concurrent multiprotocol support such as Zigbee+BLE and Thread+BLE. Security features such as Fault Injection Hardening (FIH) and Trusted Firmware (TF-M), which is the reference implementation of the Platform Security Architecture (PSA), are new with the NCS. Additionally, the NCS includes many new samples, including Matter, BLE Audio, Edge Impulse Machine Learning and more. API’s for Cloud services such as such as AWS IoT Core, Azure IoT Hub, nRF Cloud, REST, and Location Services are included. NCS includes support for the widely used unit testing frameworks Unity and CMock.

Nordic summarizes the differences between the two SDKs here: Summary table comparing NCS and nRF5

The nRF Connect SDK makes it straightforward to manage multiple SDK versions and target boards and to port existing modules from one board to another.

NCS also has transitioned to a new bootloader and firmware update protocol based on MCUBoot. MCUboot is a secure, dual-image, open protocol firmware update solution. Firmware Over the Air (FOTA)with MCUBoot is simple to integrate into firmware applications, and it is simpler to implement a host updater for MCUBoot than with the nRF5 SDK.

NCS is built around the Zephyr RTOS, which includes a build environment. Zephyr uses KConfig and Devicetree for kernel configuration and includes the west build environment using CMake and ninja. More details around this follows next. The nRF5 SDK, on the other hand, relies on Makefiles, IDE-specific project files, or custom build systems using the ARM GNU Toolchain and nRF Command Line Tools to accomplish the equivalent functions.

NCS Components

Zephyr RTOS

Zephyr is one of the fastest growing open source RTOSes and supports many processor architectures and development boards. It is open source (GitHub: zephyrproject-rtos) and supported by the Linux Foundation, so its transparency and independent governance are attractive for many forward-looking companies to adopt it as their IoT OS platform. It has a highly configurable, security-oriented design targeted for use on connected resource-constrained devices as well as large designs.

Zephyr is an OS designed around security, and the Zephyr Security Subcommittee maintains a Security Software Overview Documentation page, which has all of the necessary security information developers may need in one place. Like the nRF5 SDK, Zephyr is also PSA Certified.

It has built-in memory protection, non-volatile storage support, BLE 5.0, IP networking stack, USB-C stack, etc.​ and built-in support for many peripherals​. Zephyr also includes a number of peripheral simulators for developing with evaluation boards before custom PCBAs are available.

Zephyr is not just an RTOS with a lot of built-in libraries. It is also a development environment and has native development support on macOS, Linux and Windows​.

For a full study, developers can start with the Zephyr Project Documentation and the main features are described below.

Zephyr Tools

Repo management

To make sure the correct version of Zephyr is in the build tree for an application, a default YAML manifest exists for each tag in the GitHub repo.​

Board Support and Device drivers

Pin Control is used to interact with SoC pin controllers. It abstracts pin configurations for peripheral devices. Pin control is represented in the Devicetree hardware description and as a C API for device driver implementations.

Devicetree for Zephyr is similar to Linux/FreeBSD Devicetree with the exception that the result is a statically derived OS, rather than a dynamically run-time configured kernel using a Devicetree “blob” as in Linux. This makes the flash footprint smaller and eliminates the time needed to dynamically probe and instantiate drivers at boot time.​

The NCS provides Device tree configurations in the form of hierarchical Device Tree Source board-level files, which are customized to reflect specific hardware and SoC settings by including Device Tree Source Include Files. Below is an example .dtsi file where a configurable setting is highlighted.

Shields

For designs or prototypes which use daughter boards (mezzanine cards, add-ons etc.) Zephyr uses Shields. Shields are used to manage the configurations of one or more add-on board variations for the application.

Kernel Configuration

KConfig is used to configure the kernel and subsystems for your application. Kernel configuration can be done using the included UI Utility, or with the nRF Connect VSCode extension. VS Code integration is discussed more below.

KConfig GUI and VSCode Utility

Build, flash, debug Toolchain

Zephyr’s west meta-tool is used to build, flash, debug and sign firmware binaries. It is a command-line tool that utilizes CMake and ninja for building and flashing. It also abstracts some git commands. It packages the arm-zephyr-eabi toolchain in the software tree.

West is the default (and preferred) tool but is not ​required. Developers can use CMake, ninja, gdb, git, etc. separately if necessary

Bootloader

Device Firmware Update (DFU) or Firmware Over The Air (FOTA) is integrated with the open source MCUBoot cross-RTOS bootloader. MCUBoot and its DFU client can be added to an application as a configuration option.

The FOTA implementation is based on MCU manager (mcumgr) which uses the Simple Management Protocol (SMP) protocol. Binaries are transferred efficiently using the Concise Binary Object Representation (CBOR) format. CBOR is a binary format which uses run-length encoding to minimize upload time.

There are a number of libraries available which implement the DFU host side for mobile and desktop devices. The DFU procedure for MCUBoot is much more straightforward than the nRF5 SDK. There are a few examples for embedded hosts, and if you wish to implement one for an as-yet unsupported language the links below will be useful:

nRF Connect Desktop

nRF Connect Desktop is an application which manages the host software for nRF Connect firmware application development. It is an installer and updater for Nordic’s various utilities, the Toolchain Manager for Mac and Windows, and Getting Started Assistant for Linux. Many of the applications are also used with the nRF5 SDK, and some of them have been updated for use with the NCS. These applications are described in more detail below.

nRF Connect Desktop

BLE Application

This application allows you to connect to and analyze BLE services and characteristics of BLE devices.​ It programs a Nordic Developer Kit board for this purpose, which is an nRF52840 DK in the example case below.

Desktop BLE Application

DTM Mode

This application allows you to configure the radio on your nRF chip to perform radio testing to verify your hardware and to prepare for testing in a certification lab.

Direct Test Mode

This application works with a Nordic Power Profiler Kit (PPK) to examine the power usage of your hardware. It can also act as a data logger to watch the power usage over a long period of time.

Power Profiler

Updated Programmer (MCUBoot)

The flash programmer has been updated to use the MCUBoot bootloader.

Programmer with MCUBoot Support

RSSI Viewer​

VSCode configurator

VSCode configurator

Use the Getting Started Assistant on Linux to configure it for development with the NCS.

VSCode Extension

The NCS VS Code extension is available for Mac, Windows, and Linux versions. It provides all firmware development views and functions needed for developing your NCS firmware, including application project management, device (board) management, flashing, debugging, viewing threads and memory, code analysis and a remote terminal for firmware that supports it.

Project Management

Here we have two different applications, peripheral_hr and peripheral_uart, either of which will be flashed to an nRF52840 DK board when built. A breakpoint is set in hrs_notify().

VSCode Extension for nRF Connect

Debugger

A debug launcher is pre-configured for VS Code. Here the debugger is stopped at the breakpoint in hrs_notify(), and the debugger output is shown along with the usual variables views and call stack.

VSCode Debugger View

Thread and Memory Viewers

Thread information is shown while at the breakpoint, and an example memory view is shown here.

Thread Viewer and Memory Viewer

A code memory report is available after the build, and an interactive viewer lets you examine RAM and ROM by a specific symbol or by navigating a tree view and sunburst diagram with the mouse.

Learning the new SDK

Summary