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, 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 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 contains the SDK manifest file that manages the repositories as one code base 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.

  • sdk-mcuboot repository - contains a fork of the MCUboot project, which provides a secure bootloader application. You can find the fork in bootloader/mcuboot after obtaining the nRF Connect SDK source code. See the documentation in Nordic Semiconductor’s MCUboot fork.

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.

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

nRF Connect SDK tools and configuration methods

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 Git Submodules 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.

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.1.99-dev2 release:

Project

Revision

zephyr

d4b8ac4db1ed463928126383281b1989d200653b

nrfxlib

303b506ec891ae6505ff1467eb868cd71ef37405

mcuboot

v1.9.99-ncs2

trusted-firmware-m

11b5f0a978afff3893143a09b4f771938a3bba5e

find-my

53e288e2594e76204d18726888eb56ae7531eb5e

homekit

ad45f481cb94825b491acde3ae059852ce4729d3

matter

v2.1.0

nrf-802154

v2.1.0

tfm-mcuboot

v1.7.2-ncs2

mbedtls-nrf

d540e87d63c1bf51856a88657c58abc021c7ad8f

memfault-firmware-sdk

0.33.2

sdk-hostap

306b36c1f02579c1988c3dbab64baac4ec7b9224

cjson

c6af068b7f05207b28d68880740e4b9ec1e4b50a

azure-sdk-for-c

308c171cb4b5eed266649012a68406487ec81fb2

cmock

f65066f15d8248e6dcb778efb8739904a4512087

cirrus

9f6b3812237fbb0d4157ba3584c13f1644fcbe3a

openthread

d3e00fbd2846c09ff29444bd7cf895d3f4cff9b6

ant

36b2ac9fd02988319e9dcebc578d8f9a9f5ff892

canopennode

53d3415c14d60f8f4bfca54bfbc5d5a667d7e724

chre

ef76d3456db07e4959df555047d6962279528c8d

cmsis

5f86244bad4ad5a590e084f0e72ba7a1416c2edf

edtt

1ea61a390d2bfcf3b2ecdba8f8b0b98dfdffbd11

fatfs

a30531af3a95a9a3ea7d771ea8a578ebfed45514

fff

6ce5ba26486e93d5b7696a3e23f0585932c14b16

hal_nordic

f6628a30581d8d4b80954af163b83ce065e87467

hal_st

52a522ca4a8a9ec1e9bb5bb514e1ab6f102863fe

libmetal

2f586b4f1276fb075ee145421bdf6cbe5403aa41

liblc3codec

3951cf1b71ff3be086c9b9b595e473e12301337c

littlefs

652f2c5646e79b881e6f3099686ad3b7af9e216c

loramac-node

0257b50905695192d095667b1c3abb80346db1a1

lvgl

487bcde705b6f453d053f28dbba4dd9f353d1ccb

lz4

8e303c264fc21c2116dc612658003a22e933124d

mbedtls

7fed49c9b9f983ad6416986661ef637459723bcb

mipi-sys-t

a5163c1800a5243f8b05d84c942da008df4cb666

nanopb

dc4deed54fd4c7e1935e3b6387eedf21bb45dc38

net-tools

e0828aa9629b533644dc96ff6d1295c939bd713c

nrf_hw_models

93406267eca506003bcb86a86927777a32e729d9

open-amp

8d53544871e1f300c478224faca6be8384ab0d04

picolibc

e87b2fc37345a62361478f0a6efd140e14180ba5

segger

d4e568a920b4bd087886170a5624c167b2d0665e

tinycbor

9e1f34bc08123aaad7666d3652aaa839e8178b3b

tinycrypt

3e9a49d2672ec01435ffbf0d788db6d95ef28de0

TraceRecorderSource

9893bf1cf649a2c4ee2e27293f887994f3d0da5b

tf-m-tests

c99a86b295c4887520da9d8402566d7f225c974e

psa-arch-tests

f4fc2442b8e29e2a03d9899e46e5a3ea3df8c2c9

zcbor

a0d6981f14d4001d6f0d608d1a427f9bc6bb6d02

zscilib

a54986aa98db4082ac56b582843bb5b5435208a6