Introduction
The nRF Connect SDK is a scalable and unified software development kit for building low-power wireless applications based on the Nordic Semiconductor nRF52, nRF53, nRF70, and nRF91 Series wireless devices. It offers an extensible framework for building size-optimized software for memory-constrained devices as well as powerful and complex software for more advanced devices and applications.
It integrates the Zephyr™ real-time operating system (RTOS) and a wide range of complete applications, samples, and protocol stacks such as Bluetooth® Low Energy, Bluetooth mesh, Matter, Thread/Zigbee, Wi-Fi®, and LTE-M/NB-IoT/GPS, TCP/IP. It also includes middleware such as CoAP, MQTT, LwM2M, various libraries, hardware drivers, Trusted Firmware-M for security, and a secure bootloader (MCUboot).
Repositories
The nRF Connect SDK is a combination of software developed by Nordic Semiconductor and open source projects, hosted as Git repositories in the nrfconnect GitHub organization.
The sdk-nrf repository is the manifest repository.
It contains the SDK’s west manifest file that lists all the SDK’s repositories and their revisions.
This code base is managed with the West tool.
Some notable repositories include:
sdk-nrf repository - Contains applications, samples, libraries, and drivers that are specifically targeted at Nordic Semiconductor devices.
sdk-nrfxlib repository - Contains closed-source libraries and modules in binary format. See the nrfxlib documentation.
sdk-zephyr repository - Contains a fork of the Zephyr project, which provides samples, libraries, and drivers for a wide variety of devices, including Nordic Semiconductor devices. See the documentation in Nordic Semiconductor’s Zephyr fork.
Note
The sdk-zephyr repository is a soft fork that Nordic Semiconductor maintains. It is not the same as Zephyr SDK, which is a set of installation tools used while installing the nRF Connect SDK.
sdk-mcuboot repository - Contains a fork of the MCUboot project, which provides a secure bootloader application. You can find the fork in
bootloader/mcubootafter obtaining the nRF Connect SDK source code. See the documentation in Nordic Semiconductor’s MCUboot fork.
All repositories with the prefix sdk contain the nRF Connect SDK firmware and code.
Every nRF Connect SDK release consists of a combination of all included repositories at different revisions.
See the nRF Connect SDK repository revisions section for a comprehensive list of repositories and their current revisions.
The revision of each of those repositories is determined by the current revision of the main (manifest) repository sdk-nrf.
Versions and revisions
The nRF Connect SDK uses a versioning scheme similar to Semantic versioning, but with important semantic differences.
Every release of the nRF Connect SDK is identified with a version string, in the format MAJOR.MINOR.PATCH.
The version numbers are incremented based on the following criteria:
The
MAJORversion number is increased seldom, whenever a release is deemed to be introducing a large number of substantial changes across the board.The
MINORversion number is increased every time a major release is cut. Minor releases are the default types of an nRF Connect SDK release. They introduce new functionality and may break APIs.The
PATCHversion number is increased whenever a minor or bugfix release is cut. Patch releases only address functional issues but do not introduce new functionality.
In between releases, nRF Connect SDK is not static.
Instead, it changes its revision every time a Git commit is merged into the sdk-nrf repository.
The revision of the SDK is considered to be equivalent to the repository revision of sdk-nrf, because it is the manifest repository.
This means that, by virtue of containing the west manifest file, its revision uniquely identifies the revisions of all other repositories included in the SDK.
A special value of 99 for the PATCH version number indicates that the version string does not belong to a release, but rather a point in between two major releases.
For example, 2.2.99 indicates that this particular revision of the nRF Connect SDK is somewhere between versions 2.2.0 and 2.3.0.
In between releases, there might be development tags.
These are identified by a -devN suffix included after the nRF Connect SDK version, for example v1.9.99-dev1 for the main branch or v1.9.2-dev1 for the release branch.
Such versions indicate a snapshot of the development state that is created to highlight the introduction of a new piece of functionality.
Unlike an nRF Connect SDK release, a -devN version may or may not have received the same amount of testing.
Revisions can either be Git SHAs or tags, depending on whether the current revision is associated with a release (in which case it is a tag) or is just any revision in between releases.
For a more formal description of versions and revisions, see Revisions.
Tools and configuration
The figure below visualizes the tools and configuration methods in the nRF Connect SDK. They are based on the Zephyr project. All of them have a role in the creation of an application, from configuring the libraries or applications to building them.
nRF Connect SDK tools and configuration methods
Configuration System (Kconfig) generates definitions that configure libraries and subsystems.
Devicetree describes the hardware.
CMake generates build files based on the provided
CMakeLists.txtfiles, which use information from Kconfig and devicetree. See the CMake documentation.Ninja (comparable to make) uses the build files to build the program, see the Ninja documentation.
The GCC compiler creates the executables.
Git
Git is a free and open source distributed version control system that allows managing the changes in the code or other collections of information (set of files) over time.
Git offers a lot of flexibility in how users manage changes, and repositories are easily duplicated. In nRF Connect SDK, forking is the agreed-upon Git workflow. To contribute, the official public repository in GitHub is forked.
A fork can be hosted on any server, including a public Git hosting site like GitHub. It is, however, important to differentiate between the generic concept of a fork and GitHub’s concept of a GitHub fork. When you create a GitHub fork, GitHub copies the original repository and tags the downstream repository (the fork) with a flag that allows users to send pull requests from the fork to its upstream repository. GitHub also supports creating forks without linking them to the upstream repository. See the GitHub documentation for information about how to do this.
West
The Zephyr project includes a tool called west. The nRF Connect SDK uses west to manage the combination of multiple Git repositories and versions.
Some of west’s features are similar to those provided by submodules of Git and Google’s Repo tool. But west also includes custom features required by the Zephyr project that were not sufficiently supported by the existing tools.
West’s workspace contains exactly one manifest repository, which is a main Git repository containing a west manifest file.
Additional Git repositories in the workspace managed by west are called projects.
The manifest repository controls which commits to use from the different projects through the manifest file.
In the nRF Connect SDK, the main repository sdk-nrf contains a west manifest file west.yml, that determines the revision of all other repositories.
This means that sdk-nrf acts as the manifest repository, while the other repositories are projects.
When developing in the nRF Connect SDK, your application will use libraries and features from folders that are cloned from different repositories or projects. The west tool keeps control of which commits to use from the different projects. It also makes it fairly simple to add and remove modules.
See Getting started for information about how to install the nRF Connect SDK and about the first steps. See Development model for more information about the nRF Connect SDK code base and how to manage it.
Applications
To start developing your application you need to understand a few fundamental concepts. Follow the Zephyr guide to Application Development and browse through the included reference applications in the nRF Connect SDK to get familiar with the basics.
You also need to decide how to structure your application. You can choose from a few alternative user workflows, but having the application as the manifest repository is recommended. An ncs-example-application repository is provided to serve as a reference or starting point.
Licenses
Licenses are located close to the source files.
You can find a LICENSE file, containing the details of the license, at the top of every nRF Connect SDK repository.
Each file included in the repositories also has an SPDX identifier that mentions this license.
If a folder or set of files is open source and included in nRF Connect SDK under its own license (for example, any of the Apache or MIT licenses), it will have either its own LICENSE file included in the folder or the license information embedded inside the source files themselves.
You can use the west ncs-sbom utility to generate a license report. It allows you to generate a report for the nRF Connect SDK, built application, or specific files. The tool is highly configurable. It uses several detection methods, such as:
Search based on SPDX tags.
Search license information in files.
The Scancode-Toolkit.
Depending on your configuration, the report is generated in HTML or SPDX, or in both formats. See the Software Bill of Materials documentation for more information.
Documentation pages
The documentation consists of several inter-linked documentation sets, one for each repository.
The entry point is the nRF Connect SDK documentation that you are currently reading. The local Zephyr documentation is a slightly extended version of the official Zephyr Project documentation, containing some additions specific to Nordic Semiconductor. The local MCUboot documentation is a slightly extended version of the official MCUboot documentation, containing some additions specific to Nordic Semiconductor.
You can switch between these documentation sets by using the navigation bar at the top of the page.
To access different versions of the nRF Connect SDK documentation, use the version drop-down in the top right corner. A “99” at the end of the version number of this documentation indicates continuous updates on the main branch since the previous major.minor release.
The nRF Connect SDK documentation contains all information that is specific to the nRF Connect SDK and describes our libraries, samples, and applications. API documentation is extracted from the source code and included with the library documentation.
For instructions about building the documentation locally, see Building the nRF Connect SDK documentation. For more information about the documentation conventions and templates, see About this documentation.
nRF Connect SDK repository revisions
The following table lists all the repositories (and their respective revisions) that are included as part of nRF Connect SDK 2.3.0 release:
Project |
Revision |
|---|---|
zephyr |
|
nrfxlib |
|
mcuboot |
|
trusted-firmware-m |
|
find-my |
|
homekit |
|
matter |
|
nrf-802154 |
|
mbedtls |
|
memfault-firmware-sdk |
|
sdk-hostap |
|
cjson |
|
azure-sdk-for-c |
|
cmock |
|
cirrus |
|
openthread |
|
ant |
|
canopennode |
|
chre |
|
cmsis |
|
edtt |
|
fatfs |
|
hal_nordic |
|
hal_st |
|
hal_wurthelektronik |
|
libmetal |
|
liblc3 |
|
littlefs |
|
loramac-node |
|
lvgl |
|
lz4 |
|
mipi-sys-t |
|
nanopb |
|
net-tools |
|
nrf_hw_models |
|
open-amp |
|
picolibc |
|
segger |
|
tinycbor |
|
tinycrypt |
|
TraceRecorderSource |
|
tf-m-tests |
|
psa-arch-tests |
|
uoscore-uedhoc |
|
zcbor |
|
zscilib |