Feedback
Feedback

If you are having issues with the exercises, please create a ticket on DevZone: devzone.nordicsemi.com
Click or drag files to this area to upload. You can upload up to 2 files.

Board definition

v2.9.0 – v2.7.0

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:

  • Devicetree files that describe your hardware, which SoC (or SoCs) used, peripheral configurations, etc.
  • Kconfig files for RTOS/software needed for your hardware.
  • YML files that describe different metadata, including the high-level metadata of the board, such as the board’s names, their SoC(s), revisions, and variants.
  • Optionally .c code for special initiation procedures required for your hardware.   
  • Optionally, documentation for your hardware.

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:

  • SoC configuration: This includes specifying the exact SoC(s) used on the board (Ex: nRF54L15 QFAA), along with information about clock frequencies, memory configurations, and other hardware-specific details.
  • Peripheral configuration: Different SoC(s) may have varying sets of peripherals, such as UARTs, SPI controllers, TWI controllers, GPIOs, timers, and more. The board definition configures these peripherals to match the specific hardware on the board.
  • Memory configuration: The board definition specifies memory layout, such as RAM and Flash memory sizes, and memory regions (partitions) used for application, internal storage, bootloader, and other software components.
  • Pin mapping: SoCs have multiple pins that can be configured for different functions (e.g., GPIO, UART, SPI). The board definition provides the mapping between these pins and their corresponding functions.
  • Clock configuration: The clock configuration for the SoCs is set in the board definition to ensure accurate timing across the system.
  • Interrupt configuration: The assignment and configuration of interrupt vectors and priorities for different peripherals are also covered in the board definition.
  • Driver configuration: The board definition includes configuration options for these drivers, specifying parameters like transport settings, clock settings, etc.
  • Special Initialization Routines: The board definition may include custom initialization routines that are specific to the board, such as configuring special bootloader configuration, hardware muxes configration, or special PMIC features.

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.

Hardware support hierarchy (HWMv2)

nRF Connect SDK uses the same hardware support hierarchy used by Zephyr, which is divided into layers, from most to least specific.

  • Board: particular SoC/SiP instance(s) and its peripherals in a concrete hardware specification
  • SoC: the exact system on a chip (s) the board’s CPU(s) is part of (Provided by nRF Connect SDK/Zephyr)
  • SoC Family: a wider group of SoCs with similar characteristics (Provided by nRF Connect SDK/Zephyr)
  • SoC Series: a smaller group of tightly related SoCs (Provided by nRF Connect SDK/Zephyr)
  • CPU Core: a particular CPU in an architecture (Provided by nRF Connect SDK/Zephyr)
  • Architecture: an instruction set architecture (Provided by nRF Connect SDK/Zephyr)

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:

BoardSoCSoC family SoC SeriesCPU CoreArchitecture
nrf52833dknRF52833
or nRF52820 (Emulation)
nRF5 FamilynRF52Arm Cortex-M4Arm
nrf54l15dknRF54L15 nRF5 Family nRF54LArm Cortex-M33 & Nordic VPR Arm & RISC-V
nrf5340dknRF5340nRF5 Family
nRF53Arm Cortex-M33Arm

A note on drivers

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.

More on this

We will take a look at how to create your own custom driver in Lesson 7 – Device driver model of this course.

v2.6.2 – v2.5.2

Important

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:

  • Devicetree files that describe your hardware, which SoC used, peripheral configurations, etc.
  • Kconfig files for RTOS/software needed for your hardware.
  • Optionally .c code for special initiation procedures required for your hardware.   
  • Optionally, documentation for your hardware.

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:

  • SiP/SoC configuration: This includes specifying the exact SoC/SiP used on the board, along with information about clock frequencies, memory configurations, and other hardware-specific details.
  • Peripheral configuration: Different SoCs/SiPs may have varying sets of peripherals, such as UARTs, SPI controllers, TWI controllers, GPIOs, timers, and more. The board definition configures these peripherals to match the specific hardware on the board.
  • Memory configuration: The board definition specifies memory layout, such as RAM and Flash memory sizes, and memory regions used for application and bootloader.
  • Pin mapping: SoCs/SiPs have multiple pins that can be configured for different functions (e.g., GPIO, UART, SPI). The board definition provides the mapping between these pins and their corresponding functions.
  • Clock configuration: The clock configuration for the SoCs/SiPs is set in the board definition to ensure accurate timing across the system.
  • Interrupt configuration: The assignment and configuration of interrupt vectors and priorities for different peripherals are also covered in the board definition.
  • Driver configuration: The board definition includes configuration options for these drivers, specifying parameters like baud rates for UARTs or clock settings for timers.
  • Special Initialization Routines: The board definition may include custom initialization routines that are specific to the board, such as configuring special bootloader configration or muxes configration.

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.

Hardware support hierarchy

nRF Connect SDK uses the same hardware support hierarchy used by Zephyr, which is divided into layers, from most to least specific:

  • Board: a particular SoC instance and its peripherals in a concrete hardware specification (You need to write this for your custom hardware)
  • SoC: the exact system on a chip the board’s CPU is part of (Provided by nRF Connect SDK/Zephyr).
  • SoC Series: a smaller group of tightly related SoCs (Provided by nRF Connect SDK/Zephyr)
  • SoC Family: a wider group of SoCs with similar characteristics (Provided by nRF Connect SDK/Zephyr)
  • CPU Core: a particular CPU in an architecture (Provided by nRF Connect SDK/Zephyr)
  • Architecture: an instruction set architecture (Provided by nRF Connect SDK/Zephyr)

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:

BoardSoCSoC SeriesSoC familyCPU CoreArchitecture
nrf52833dk_nrf52833nRF52833nRF52nRF5 FamilyArm Cortex-M4Arm
nrf5340dk_nrf5340_cpuappnRF5340nRF53nRF5 FamilyArm Cortex-M33Arm
nrf9160dk_nrf9160nRF9160nRF91nRF9 FamilyArm Cortex-M33Arm

A note on drivers

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.

More on this

We will take a look at how to create your own custom driver in Lesson 7 – Device driver model of this course.

Register an account
Already have an account? Log in
(All fields are required unless specified optional)

  • 8 or more characters
  • Upper and lower case letters
  • At least one number or special character

Forgot your password?
Enter the email associated with your account, and we will send you a link to reset your password.