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

Board definition

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 initiatation 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.