When developing applications with nRF Connect SDK, the concept of a “board” is really at the center of the development. nRF Connect SDK has high portability embedded in it based on Zephyr RTOS concepts.
A Board is simply the target hardware you want to build an application to. The concept of boards can help you make your application work on different types of hardware ”boards”. For instance, moving your code from one development kit, like the nRF52840 DK, to another, like nRF54L15 DK, can be quite straightforward. Also, moving your application from a development kit, like the nRF54L15 DK, to your own custom hardware can also be quite straightforward.
In nRF Connect SDK, hardware is no longer described in C header files, it is highly decoupled from your application through the use of Devicetree/Kconfig.
So this brings us to what a “board” is regarding nRF Connect SDK/Zephyr. Think of a “board” as a folder that contains several things:
A board definition generally refers to configuration and initialization files that define the hardware characteristics and behavior of a specific development board or hardware platform.
A board definition includes information about various hardware aspects of the board, such as:
This may sound a bit intimidating; luckily, we don’t have to write all of these ourselves if we want to add a new custom board. This is due to how hardware support is structured within the SDK, as covered in the next paragraph. The SDK will provide most configurations, specifically for the Architecture, CPU, SoC Series, SoC Family, SoC.
nRF Connect SDK uses the same hardware support hierarchy used by Zephyr, which is divided into layers, from most to least specific.
The implementation of the layers has changed from nRF Connect SDK v2.7.0. Starting from nRF Connect SDK v2.7.0, Hardware Model V2 (HWMv2) is the default board system. HWMv2 is an improved and extensible system for defining boards intended to completely replace the old system (HWMv1).
One of the main challenges of the old (HWMv1) model was that it did not handle boards with multiple targets very well. It was mainly intended for hardware with a single target, meaning the hardware had one SoC with one CPU running an application. When the hardware has different targets whether it’s multi cores or multi SoC, or even multiple architectures, the board definition needs to be implemented in a complicated way with files scattered in different folders. It basically does not fit the demands of modern hardware. Therefore, HWMv2 was born as an improved and extensible system for defining boards both in nRF Connect SDK and upstream Zephyr.
With HWMv2, boards, are no longer located under architecture. The reasoning here is that a single board could have multiple architectures; instead, board files are now located under their vendor.
HWMv2 offers reusability in Sysbuild which means you can select to generate extra images for things like MCUboot or network cores in a more coupled way.
There is a new common description format for everything from the Borads, SoC, Series, Family, Architecture, CPU cluster, variants, and revisions. The new common description is Yaml-based (.yml or .yaml); we will dive into this in the next Creating board files topic. The common description of Yaml files lays the foundation of a flexible and extensible system for defining boards.
To understand these layers in HWMv2, let’s take the nRF9160 DK example, the nRF9160 DK contains two SoCs: nRF9160 and nRF52840. Both of these SoCs belong to the Nordic nRF Family. The nRF9160 belongs to the nRF91 Series, which hosts an ARM Cortex M33 CPU, while the nRF52840 belongs to the nRF52 Series, which hosts an ARM Cortex M4 CPU. The purple boxes are provided by the SDK, while the board files for your custom board are what you need to write, which we will cover in this lesson.
The architecture of Nordic SoCs/SiPs will usually be Arm and, in some cases, RISC-V for the co-processors on the nRF54 Series.
Let’s take more examples of Nordic development kits:
Board | SoC | SoC family | SoC Series | CPU Core | Architecture |
---|---|---|---|---|---|
nrf52833dk | nRF52833 or nRF52820 (Emulation) | nRF5 Family | nRF52 | Arm Cortex-M4 | Arm |
nrf54l15dk | nRF54L15 | nRF5 Family | nRF54L | Arm Cortex-M33 & Nordic VPR | Arm & RISC-V |
nrf5340dk | nRF5340 | nRF5 Family | nRF53 | Arm Cortex-M33 | Arm |
In addition to the hardware support hierarchy for the target SoC where the application will be running. Drivers are needed when external components (e.g. sensors) are connected to your SoC peripherals, like I2C, SPI, etc. Drivers are specified through the compatible
property in the Devicetree.
Drivers will not reside in the board folder. They have dedicated locations within nRF Connect SDK and Zephyr. The good news is that there is a long list of already implemented drivers for things like sensors. Nevertheless, if you have a component on your custom board with no driver yet, neither in Zephyr nor in nRF Connect SDK, you will need to implement it. Examples of boards with sensors: micro:bit v2, Thingy:53 , Thingy:91 , Thingy:91 X.
We will take a look at how to create your own custom driver in Lesson 7 – Device driver model of this course.
This exercise tab is for nRF Connect SDK v2.6.2 -v2.5.2, where Hardware Model V1 (HWMv1) is used. HWMv1 is deprecated and will be removed in nRF Connect SDK v3.0.0. Use HWMv2 for all new designs (Tab v2.8.x-v2-7.0).
Either watch the video or read the text below the video:
When developing applications with nRF Connect SDK, the concept of a “board” is really at the center of the development. nRF Connect SDK has high portability embedded in it based on Zephyr RTOS concepts.
A Board is simply the target hardware you want to build an application to. The concept of boards can help you make your application work on different types of hardware ”boards”. For instance, moving your code from one development kit, like the nRF52840 DK, to another, like nRF5340 DK, can be quite straightforward. Also, moving your application from a development kit, like the nRF5340 DK, to your own custom hardware can also be quite straightforward.
In nRF Connect SDK, hardware is no longer described in C header files, it is highly decoupled from your application through the use of Devicetree/Kconfig.
So this brings us to what a “board” is regarding nRF Connect SDK/Zephyr. Think of a “board” as a folder that contains several things:
A board definition generally refers to configuration and initialization files that define the hardware characteristics and behavior of a specific development board or hardware platform.
A board definition includes information about various hardware aspects of the board, such as:
This may sound a bit intimidating; luckily, we don’t have to write all of these ourselves if we want to add a new custom board. This is due to how hardware support is structured within the SDK, as covered in the next paragraph. The SDK will provide most configurations, specifically for the Architecture, CPU, SoC Series, SOC/SiP.
nRF Connect SDK uses the same hardware support hierarchy used by Zephyr, which is divided into layers, from most to least specific:
You can visualize the hierarchy like this:
The architecture in the case of nRF Connect SDK will be, most of the time ARM and, in some cases RISC-V for the coprocessors on the nRF54H series.
Let’s take the example of some of Nordic development kits:
Board | SoC | SoC Series | SoC family | CPU Core | Architecture |
---|---|---|---|---|---|
nrf52833dk_nrf52833 | nRF52833 | nRF52 | nRF5 Family | Arm Cortex-M4 | Arm |
nrf5340dk_nrf5340_cpuapp | nRF5340 | nRF53 | nRF5 Family | Arm Cortex-M33 | Arm |
nrf9160dk_nrf9160 | nRF9160 | nRF91 | nRF9 Family | Arm Cortex-M33 | Arm |
In addition to the hardware support, hierarchy for the target SoC where the application will be running. Drivers are needed when external components (e.g. sensors) are connected to your SoC peripherals, like I2C, SPI, etc. Drivers are specified through the compatible
property in the Devicetree.
Drivers will not reside in the board files. They have dedicated locations within nRF Connect SDK and Zephyr. The good news is that there is a long list of already implemented drivers for things like sensors. Nevertheless, if you have a component on your custom board with no driver yet, neither in Zephyr nor in nRF Connect SDK, you will need to implement it. Examples of boards with sensors: micro:bit v2, Thingy:53 , Thingy:91.
We will take a look at how to create your own custom driver in Lesson 7 – Device driver model of this course.