Board support
The nRF Connect SDK provides board definitions for all Nordic Semiconductor devices. In addition, you can define custom boards.
Board names
The following tables list all boards and build targets for Nordic Semiconductor’s hardware platforms.
The build target column uses several entries for multi-core hardware platforms:
For core type:
cpuapp- When you choose this target, you build the application core firmware.cpunet- When you choose this target, you build the network core firmware.
For usage of Cortex-M Security Extensions (CMSE):
Entries without
*_ns(cpuapp) - When you choose this target, you build the application core firmware as a single execution environment that does not use CMSE (Trusted Firmware-M (TF-M)).Entries with
*_ns(for example,cpuapp_ns) - When you choose this target, you build the application with CMSE. The application core firmware is placed in Non-Secure Processing Environment (NSPE) and uses Secure Processing Environment (SPE) for security features. By default, the build system automatically includes Trusted Firmware-M (TF-M) in SPE and merges it with NSPE.
Read more about separation of processing environments in the Processing environments section.
Boards included in sdk-zephyr
The following boards are defined in the zephyr/boards/arm/ folder.
Also see the Supported Boards section in the Zephyr documentation.
Hardware platform |
PCA number |
Board name |
Build target |
|---|---|---|---|
nRF52 DK (nRF52832) |
PCA10040 |
|
|
|
|||
|
|||
nRF52833 DK |
PCA10100 |
|
|
|
|||
nRF52840 DK |
PCA10056 |
|
|
|
|||
nRF52840 Dongle |
PCA10059 |
|
|
Thingy:52 |
PCA20020 |
|
|
nRF21540 DK |
PCA10112 |
|
|
nRF5340 DK |
PCA10095 |
|
|
Thingy:53 |
PCA20053 |
|
|
nRF9160 DK |
PCA10090 |
|
|
|
Note
In nRF Connect SDK releases before v1.6.1:
The build target
nrf9160dk_nrf9160_nswas namednrf9160dk_nrf9160ns.The build target
nrf5340dk_nrf5340_cpuapp_nswas namednrf5340dk_nrf5340_cpuappns.
Boards included in sdk-nrf
The following boards are defined in the nrf/boards/arm/ folder.
Hardware platform |
PCA number |
Board name |
Build target |
|---|---|---|---|
nRF5340 Audio |
PCA10121 |
|
|
nRF Desktop Gaming Mouse |
PCA20041 |
|
|
nRF Desktop Mouse |
PCA20044 |
|
|
nRF Desktop Mouse |
PCA20045 |
|
|
nRF Desktop Keyboard |
PCA20037 |
|
|
nRF Desktop Dongle |
PCA10111 |
|
|
nRF Desktop Dongle |
PCA10114 |
|
|
Thingy:91 |
PCA20035 |
|
|
|
|||
nRF7002 DK |
PCA10143 |
|
The nRF21540 EK shield is defined in the nrf/boards/shields folder.
Custom boards
Defining your own board is a very common step in application development, because applications are typically designed to run on boards that are not directly supported by the nRF Connect SDK, and are often custom designs not available publicly. To define your own board, you can use the following Zephyr guides as reference, since boards are defined in the nRF Connect SDK just as they are in Zephyr:
Custom Board, Devicetree and SOC Definitions is a guide to adding your own custom board to the Zephyr build system.
Board Porting Guide is a complete guide to porting Zephyr to your own board.
One of the nRF Connect SDK applications that lets you add custom boards is nRF Desktop. See Integrating your own hardware in the application documentation for details.
Processing environments
The build target column in the tables above separates entries according to the CPU to target (for multi-core SoCs) and whether Cortex-M Security Extensions (CMSE) are used or not (addition of _ns if they are used).
When CMSE is used, the firmware is split in accordance with the security by separation architecture principle to better protect sensitive assets and code. With CMSE, the firmware is stored in one of two security environments (flash partitions), either Secure Processing Environment (SPE) or Non-Secure Processing Environment (NSPE). This isolation of firmware is only possible if the underlying hardware supports ARM TrustZone.
Processing environments in the nRF Connect SDK
In Zephyr and the nRF Connect SDK, SPE and NSPE are used exclusively in the context of the application core of a multi-core SoC. Building follows the security by separation principle and depends on the build target.
Building for cpuapp (CMSE disabled)
When you build for cpuapp, you build the firmware for the application core without CMSE.
Because CMSE is disabled, TF-M is not used and there is no separation of firmware.
Building for *_ns (CMSE enabled)
When you build for *_ns, you build firmware with CMSE.
Firmware is separated in the following way:
SPE implements security-critical functionality and data (including bootloaders) and isolates them from the application software in NSPE. It also contains secure firmware running in the secure state.
NSPE typically implements the user application and communication firmware, among other major components.
The application is built as a non-secure image and Trusted Firmware-M (TF-M) is built as the secure image. The build system merges both images to form a combined image that will be used for programming or updating the device.
TF-M enables hardware-supported separation of firmware. It also implements Platform Security Architecture (PSA) API, which provides security features for the system, including roots of trust for protecting secrets, platform state, and cryptographic keys. The API coordinates the communication with the components in NSPE.
More information about SPE and NSPE
Read the following pages for a better understanding of security by separation in the nRF Connect SDK: