About the nRF Connect SDK

The nRF Connect SDK enables you to develop applications for nRF52, nRF53, and nRF91 Series devices. It is a combination of software developed by Nordic Semiconductor and open source projects, hosted as Git repositories in the nrfconnect GitHub organization.

Every nRF Connect SDK release consists of a combination of all those repositories at different revisions. See the Repositories and 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, which contains the SDK manifest file that helps manage 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.

About the nRF Connect SDK license

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.

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.

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 organizes data (files or directories) in project repositories. The data is managed like a series of snapshots. Every time you commit, or save the state of your project, Git takes a snapshot of what the files look like at that exact moment and stores a reference to that snapshot. For unchanged files, Git provides just a link to the previous identical file it has already stored.

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.

When you say you are forking a repository, you are creating a copy of the repository under your GitHub ID. This means that you are creating an identical copy that might diverge from the original over time. This copy is your personal public repository that nobody else is allowed to push to, but changes can be pulled from it.

The original repository is called the upstream repository, and the newly created copy the downstream repository. Any changes made to the original repository are reflected back to your forked repositories by using fetch and rebase commands.

A git clone command is used to get a copy of your downstream repository onto your local machine. This serves as a private development environment.

Local commits are pushed to your own downstream repository, and not the official one. To integrate the changes into the main upstream repository, a pull request is created explicitly. Before it is merged, the pull request also serves as a convenient discussion thread if there are issues with the contributed code. If your pull request is approved, the changes are merged with the existing original content. Until then, your changes are reflected only in the copy you 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 respository. See the GitHub documentation for information about how to do this.

Everything in Git is checksummed before it is stored and is then referred to by that checksum. The mechanism that Git uses for this checksumming is called a SHA-1 hash. This hash is a 40-character string, composed of hexadecimal characters (0–9 and a–f), and calculated based on the contents of a file or directory structure in Git.

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.

For more details about the reasons behind the introduction of west, see the History and Motivation section of the Zephyr documentation.

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.

Some west commands are related to Git commands with the same name, but operate on the entire west workspace. Some west commands take projects as arguments. The two most important workspace-related commands in west are west init and west update.

The west init command creates a west workspace, and you typically need to run it only once to initialize west with the revision of the nRF Connect SDK that you want to check out. It clones the manifest repository into the workspace. However, the content of the manifest repository is managed using Git commands, since west does not modify or update it.

To clone the project repositories, use the west update command. This command makes sure your workspace contains Git repositories matching the projects defined in the manifest file. Whenever you check out a different revision in your manifest repository, you should run west update to make sure your workspace contains the project repositories the new revision expects (according to the manifest file).

For more information about west init, west update, and other built-in commands, see Built-in commands.

For more information about the west tool, see the West (Zephyr’s meta-tool) user guide.

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.

Repositories and revisions

The following table lists all the repositories (and their respective revisions) that are included as part of nRF Connect SDK 1.9.99 release:

Project

Revision

zephyr

3c8a7f7ad6d2458a3bcc30a22ef62323db87ed56

nrfxlib

9927d515e1cf62bc399c36cb1620c15dc34e869f

mcuboot

v1.9.99-ncs1-rc2

trusted-firmware-m

v1.5.0-ncs2-rc2

find-my

v2.0.0-rc2

homekit

f7ca2290c05ed0ba54e4d6616aa25c459607ebc3

matter

v2.0.0-rc2

nrf-802154

v2.0.0-rc1

tfm-mcuboot

v1.7.2-ncs1

mbedtls-nrf

v3.0.0-ncs2-rc1

memfault-firmware-sdk

0.29.1

cjson

c6af068b7f05207b28d68880740e4b9ec1e4b50a

sdk-lc3

c47d9ee21c9cd8626a903c2e2f0c80c0920a1eb8

cmock

9d092898ef26ece140d9225e037274b64d4f851e

unity

74cde089e65c3435ce9aa87d5c69f4f16b7f6ade

zcbor

3d36ae19cb05d28cea23b4c870ae965c44215e9c

cirrus

9f6b3812237fbb0d4157ba3584c13f1644fcbe3a

canopennode

53d3415c14d60f8f4bfca54bfbc5d5a667d7e724

chre

0edfe2c2ec656afb910cfab8ed59a5ffd59b87c8

civetweb

094aeb41bb93e9199d24d665ee43e9e05d6d7b1c

cmsis

ed63b704bbfaceb71220557b658304c5ea3d5b88

edtt

1ea61a390d2bfcf3b2ecdba8f8b0b98dfdffbd11

fatfs

9237454a30bcf6e14a89db174e8dbeb8f31831d2

fff

6ce5ba26486e93d5b7696a3e23f0585932c14b16

hal_nordic

a85bb3676d61d1ae202088e0d3fec556056b2c9e

hal_st

575de9d461aa6f430cf62c58a053675377e700f3

libmetal

c6efe091dfe02704097586a522969b5a4cc197bd

liblc3codec

3951cf1b71ff3be086c9b9b595e473e12301337c

littlefs

7b2cf4ba759bd530b543644e2790b07cf20cd6aa

loramac-node

12019623bbad9eb54fe51066847a7cbd4b4eac57

lvgl

a2e17073e5208c221e24e3c2b3b6c473e878bd1e

lz4

8e303c264fc21c2116dc612658003a22e933124d

mbedtls

3e3e58a92de76069730c63e0d524f40fea948a61

mipi-sys-t

2f51407b2ac68e2be41af322a42905063f009d75

nanopb

d148bd26718e4c10414f07a7eb1bd24c62e56c5d

net-tools

f49bd1354616fae4093bf36e5eaee43c51a55127

nrf_hw_models

b8cea37dbdc8fc58cc14b4e19fa850877a9da520

open-amp

cfd050ff38a9d028dc211690b2ec35971128e45e

openthread

e2a765599aa0379d0f72f0149a9cbafec070c12d

segger

3a52ab222133193802d3c3b4d21730b9b1f1d2f6

tinycbor

9e1f34bc08123aaad7666d3652aaa839e8178b3b

tinycrypt

3e9a49d2672ec01435ffbf0d788db6d95ef28de0

TraceRecorderSource

e8ca3b6a83d19b2fc4738a0d9607190436e5e452

tf-m-tests

52814181f0fde6d1422fac204d42cde30c62e40e

psa-arch-tests

4f45df539d3d98b6e38e112be9936be4a2b8a97c

zscilib

12bfe3f0a9fcbfe3edab7eabc9678b6c62875d34