This lesson covers how to define boards in the nRF Connect SDK using both hardware models v1 and v2 (HWMv1 and HWMv2 respectively).
This exercise tab covers nRF Connect SDK where HWMv2 is used, which is recommended for all new designs.
In this topic, we will explore the different options for creating custom board files and the guidelines for naming your custom board.
We will cover the mandatory and optional files required to define a custom board in HWMv2, as well as how to create a revision of the board. We will study these files one by one and understand their role.
In Exercise 1 of this lesson, we will use the Create a new board GUI in the nRF Connect for VS Code extension to define a new board, and populate most of the mandatory files’ content.
Board terminology (in HWMv2)
In Hardware Model version 2, each board has a unique board name (sometimes referred to as the board ID).
The Create a new board GUI function in the nRF Connect for VS Code extension will ask you to provide both a board name and a human-readable name for your board. The human-readable name can include white spaces or capital letters (e.g., My nRF54L DK, DevAcademyL3E1), and is intended for display purposes and documentation. The board name is commonly a lower-case and underscore-separated version of the human-readable name (e.g., my_nrf54l_dk, devacademyl3e1).
Definition
Human-readable name (full_name) is the descriptive name for the board, which can include spaces and capital letters. The full name is intended for display purposes and documentation, making it easier for users to recognize the board.
Board name is typically a lowercase, underscore-separated version of the human-readable name, with all whitespaces replaced by underscores. The board name uniquely and descriptively identifies a particular system, but does not include additional information that may be required to actually build an image.
When naming your custom board, you need to give your board a unique name. Run west boards in the nRF Connect Terminal for a list of names that have already been taken; you can’t name your custom board with a name that is already in use.
In HWMv2, the name of the SoC is no longer needed at the end of the board name. Instead, this is specified explicitly in one of the files in the board definition (board.yml file).
In addition to the board name, a board will have one or more board qualifiers.
Let’s examine the board terminology used in HWMv2, using the BL5340 DVK from Ezurio as an example, which is based on the nRF5340 SoC.
Board target: The full string that can be provided to any of the Zephyr build tools (e.g., west) to compile and link an image for a particular hardware system. Boards with single-core SoCs typically have one board target, while more advanced boards with multiple SoCs or multi-core SoCs will have several board targets.
Board name: The name of the board without spaces.
Board revision (optional): This is used to capture new changes in new hardware versions (new schematics, new PCB).
Board qualifiers: The set of additional tokens, separated by a forward slash / that follows the board name (and optionally board revision).
SoC: The specific SoC used on the board.
CPU cluster: This is defined by the SoC layer. If the SoC does not have any clusters, this is omitted.
Variant: In the context of board qualifiers, a variant designates a particular type or configuration of a build for a combination of SoC and CPU clusters. Common uses of the variant concept include introducing both secure and non-secure builds for platforms with Trusted Firmware-M support, or selecting the type of RAM used in a build. Another use of variants is for different builds of hardware (not a revision). For example, if you have a board that includes sensors and another exact one that does not include sensors.
Consider a board with the human-readable name DevAcademy L3E1, based on the nRF52833 SoC. The board will have the board name devacademyl3e1, and the board target devacademyl3e1/nrf52833. The board can have an optional revision that can be specified as [email protected]/nrf52833 and it could have an optional variant [email protected]/nrf52833/sense.
Note
The CPU clusters are defined by the SoC layer, and the nRF52833 SoC does not have any clusters.
Location of custom board
Before diving into the board files that make up the custom board definition, we need to know where to put the files.
When working with custom boards, you have three main options for where to place the board definition files. Each option has its own advantages and limitations:
Out-of-Tree (dedicated directory): In this approach, your board files are stored outside of the nRF Connect SDK/Zephyr tree in a separate directory. You’ll configure the build system to locate and use these external board files. This method is ideal for closed-source projects where you want to keep board definitions private. This is the method we’ll focus on in this lesson.
Upstream in Zephyr: Choose this option if you’re developing a development kit, module, reference design, or prototyping platform that you intend to share with the Zephyr community. It’s also appropriate for open-source products. Board definitions submitted upstream must include documentation and go through a review and approval process by the Zephyr maintainers.
Inside the application’s boards folder: This option is suitable for quick prototyping or debugging. You can place the board files directly in a boards subdirectory within your application folder. This is a convenient approach for temporary or experimental work.
Board files
Consider our new development kit DevAcademy L3E1 which is based on the nRF52833 SoC. The board name for this board will be devacademyl3e1.
When creating a custom board definition, remember that the SDK provides the hardware layer files from Architecture up to SoC. So, we only need to populate the board layer. The board layer consists of these four mandatory files.
The term <vendor> serves as a placeholder for the vendor name.
Mandatory files
Let’s take a close look at the four mandatory files in the board layer.
1. board.yml
The board.yml file is a required component introduced in Hardware Model v2 (HWMv2). Each board folder must contain one board.yml, and it serves as a central configuration file that defines key properties for your board.
Board name: Defines the board name or names.
SoC selection: At least one SoC must be specified.
Revisions: Optional; used to define specific hardware versions.
Variants: Used for special configurations, such as enabling TF-M or using a different CPU core.
While it’s technically possible to define multiple boards in one folder using a single board.yml, this is not a common use case.
When you use the extension tool and input the board name, SoC, SoC variant, and vendor, the board.yml file is generated automatically. In most cases, you won’t need to manually edit it.
Here is what a board.yml file typically looks like. You could also include full_name: in board.yml to specify the human-readable name of your board.
Let’s take a look at the board.yml files for some Nordic development kits.
board.yml examples
Single board target: The nRF52840 dongle is based on the nRF52840 SoC, a single-core device with no CPU clusters.
Quad board target: The nRF54L15 has two CPU clusters defined by the SoC layer, cpuapp and cpuflpr. The board.yml defines a new variant, xip, which is associated with cpuflpr. It also defines another variant called ns (TF-M enabled) associated with the cpuapp. So in total, there are 4 board targets.
Dual board target with revisions: The nRF9161 DK has no CPU clusters defined by the nRF9161 SiP. There is a variant, ns. It also defines two revisions: 0.9.0 (default) and 0.7.0.
2. Kconfig.devacademyl3e1
This file serves a specific and essential purpose: it selects the SoC(s) used by the board. By doing so, it pulls in the appropriate hardware layer files from Architecture up to SoC. It also defines a Kconfig symbol for the board, which is the board name prefixed with BOARD_ .
It contains select statement(s)
Only selectis needed for a single-board target
select … if statements are needed for multi-core SoCs or multi-SoC boards
Here are some examples:
Below is an example of our devacademyl3e1 (single board target) that we will develop in Exercise 1, which is based on the nRF52833 QIAA.
Copy
configBOARD_DEVACADEMYL3E1selectSOC_NRF52833_QIAA
Here is another example for the nRF54L15 DK (quad board target). The file selects the appropriate SoC support layer based on the normalized board target triggered from the build system.
3. devacademyl3e1.dts
The board-level devicetree file is a hardware description written in the devicetree format. It represents the schematics of your board, detailing its physical components and connections.
It includes connectors and any other hardware components such as LEDs, buttons, sensors, or communication peripherals (USB, BLE controller, etc). Memory partitioning is also done in this file. We will rely heavily on the automation provided by the nRF Connect for VS Code extension, including the Devicetree Visual Editor, to help us populate this file.
If your board has multiple board qualifiers (i.e., different board targets or variants), you need to create a separate board-level devicetree file for each board target. You can structure the board-level devicetree file into multiple files to improve readability and maintainability.
4. devacademyl3e1-pinctrl.dtsi
This file defines the pin-mapping of your board’s peripherals.
If your board has multiple board qualifiers (i.e., different board targets or variants), you need to create a separate pin-mapping file for each board target.
Optional files
Now that we’ve covered the four mandatory files in the board layer, let’s take a look at the optional files.
Below is a board layer consisting of all mandatory files, optional, and special use cases files:
Copy
boards/<vendor>/devacademyl3e1├── board.yml├── Kconfig.devacademyl3e1├── devacademyl3e1_<qualifiers>.dts ├── devacademyl3e1_<qualifiers>-pinctrl.dtsi├── devacademyl3e1_<qualifiers>_defconfig├── Kconfig.defconfig├── board.cmake # Used for flash and debug├── CMakeLists.txt # Needed in special cases ├── c_files.c # Needed in special cases├── doc # Optional │ ├── devacademyl3e1.png│ └── index.rst├── Kconfig # Optional to create a board Kconfig options menu├── devacademyl3e1_<qualifiers>.yml # Optional for Test Runner (Twister)├── devacademyl3e1_<qualifiers>_<revision>.conf # Needed to support hardware revisions├── devacademyl3e1_<qualifiers>_<revision>.overlay #Needed to support hardware revisions└── dts # Optional └── bindings
The term <vendor> serves as a placeholder for the vendor name. If the board has qualifiers (<qualifiers>), such as multiple SoCs, CPU clusters, or variants (e.g., multi-board target), these qualifiers must be appended to the board name to clearly indicate where you want these files to apply.
devacademyl3e1_defconfig
The devacademyl3e1_defconfig file is a Kconfig fragment that is merged as-is into the final build of any application built for the specified board.
Here is the default devacademyl3e1_defconfig file generated by the tool (differs from one SoC to another).
In addition to the default Kconfig symbols, we need to manually include any additional Kconfig symbols that we want to be enabled for all applications built for the board.
In the case of our board, DevAcademy L3E1, it’s a development kit, so we want to add UART, RTT and GPIO support. Therefore, we will append the following:
<boardname>_defconfig is a Kconfig fragment merged as-is into the final build of any application built for the specified board, and must enable the bare minimum. It’s the application configuration’s (prj.conf) responsibility to configure what is needed.
If your board has multiple board qualifiers (i.e., different board targets or variants), you need to specify the qualifiers in the name of the file (e.g., devacademyl3e1_<qualifiers>_defconfig) for it to take effect when a certain qualifier is passed to the build system.
Kconfig.defconfig
The Kconfig.defconfig file defines board-specific default values for Kconfig options. The content of this file is wrapped in if /endif blocks that correspond to specific board targets. This file is automatically generated by the tool and complements the defconfig file by setting defaults that only apply when building for a particular board.
Let’s see the example for our board which has a single board target devacademyl3e1/nrf52833.
The CONFIG_BT_CTLR Kconfig option, which enables support for the SoC native Bluetooth LE controller implementation, is only enabled if CONFIG_BT is selected by the application.
If the board has multiple board targets, you can have multiple if/endif blocks for the different board targets.
For example, in the Kconfig.defconfig file for the nRF54L15 DK.
CMakeLists.txt: Used to include source files that should be executed pre- or post-kernel. For example, if your hardware requires custom mux configurations or needs to be configured in a particular way, it can be added to this file. This is done for the nRF52840 Dongle where board_nrf52840dongle_nrf52840_init()is executed at PRE_KERNEL_1 before the kernel. Note that the extension does not create the CMakeLists.txt file; you need to manually create it if needed.
doc/index.rst,doc/devacademyl3e1.png: Documentation and image of the board, only needed if you are Contributing your board to Zephyr.
Kconfig: Allows you to create a custom Kconfig menu specific to your board.
devacademyl3e1.yml: A YAML file with miscellaneous metadata used by Zephyr’s Test Runner (Twister). If your board has multiple qualifiers, you need to have a .yml for each.
Board revisions
When you create new hardware revisions for your board, such as changes to the schematics or a new PCB layout, you do not need to create a completely new board definition. Instead, you can simply add the revision-specific files within the same board folder, devacademyl3e1_<revision>.conf and devacademyl3e1_<revision>.overlay, and update board.yml to include the revision.
Keep in mind that if your board has multiple board qualifiers, you need to specify the .conf and .overlay files to the affected qualifiers, e.g., devacademyl3e1_<qualifiers>_<revision>.conf, devacademyl3e1_<qualifiers>_<revision>.overlay.
devacademyl3e1_<revision>.conf: The optional Kconfig settings specified here will be merged into the board’s default Kconfig configuration.
devacademyl3e1_<revision>.overlay: The optional devicetree overlay will be overlayed with the board-level devacademyl3e1.dts devicetree file.
board.yml: The revision: property controls how the Zephyr build system matches the <board_name>@<revision> string specified by the user when building an application for the board.
Note
When creating a new custom board, it is always a good idea to start looking into the SDK-defined boards with the same SoC/SiP as your custom board for inspiration. There is a long list of Development Kits, Prototyping Platforms, and Reference designs already shipped in the SDK that can serve as a good starting point.
They are available in two locations <install_path>/zephyr/boards/nordic/ and <install_path>/nrf/boards/nordic/
This lesson covers how to define boards in the nRF Connect SDK using both hardware models v1 and v2 (HWMv1 and HWMv2 respectively).
This exercise tab covers nRF Connect SDK where HWMv2 is used, which is recommended for all new designs.
In this topic, we will explore the different options for creating custom board files and the guidelines for naming your custom board.
We will cover the mandatory and optional files required to define a custom board in HWMv2, as well as how to create a revision of the board. We will study these files one by one and understand their role.
In Exercise 1 of this lesson, we will use the Create a new board GUI in the nRF Connect for VS Code extension to define a new board, and populate most of the mandatory files’ content.
Board terminology (in HWMv2)
In Hardware Model version 2, each board has a unique board name (sometimes referred to as the board ID).
The Create a new board GUI function in the nRF Connect for VS Code extension will ask you to provide both a board name and a human-readable name for your board. The human-readable name can include white spaces or capital letters (e.g., My nRF54L DK, DevAcademyL3E1), and is intended for display purposes and documentation. The board name is commonly a lower-case and underscore-separated version of the human-readable name (e.g., my_nrf54l_dk, devacademyl3e1).
Definition
Human-readable name (full_name) is the descriptive name for the board, which can include spaces and capital letters. The full name is intended for display purposes and documentation, making it easier for users to recognize the board.
Board name is typically a lowercase, underscore-separated version of the human-readable name, with all whitespaces replaced by underscores. The board name uniquely and descriptively identifies a particular system, but does not include additional information that may be required to actually build an image.
When naming your custom board, you need to give your board a unique name. Run west boards in the nRF Connect Terminal for a list of names that have already been taken; you can’t name your custom board with a name that is already in use.
In HWMv2, the name of the SoC is no longer needed at the end of the board name. Instead, this is specified explicitly in one of the files in the board definition (board.yml file).
In addition to the board name, a board will have one or more board qualifiers.
Let’s examine the board terminology used in HWMv2, using the BL5340 DVK from Ezurio as an example, which is based on the nRF5340 SoC.
Board target: The full string that can be provided to any of the Zephyr build tools (e.g., west) to compile and link an image for a particular hardware system. Boards with single-core SoCs typically have one board target, while more advanced boards with multiple SoCs or multi-core SoCs will have several board targets.
Board name: The name of the board without spaces.
Board revision (optional): This is used to capture new changes in new hardware versions (new schematics, new PCB).
Board qualifiers: The set of additional tokens, separated by a forward slash / that follows the board name (and optionally board revision).
SoC: The specific SoC used on the board.
CPU cluster: This is defined by the SoC layer. If the SoC does not have any clusters, this is omitted.
Variant: In the context of board qualifiers, a variant designates a particular type or configuration of a build for a combination of SoC and CPU clusters. Common uses of the variant concept include introducing both secure and non-secure builds for platforms with Trusted Firmware-M support, or selecting the type of RAM used in a build. Another use of variants is for different builds of hardware (not a revision). For example, if you have a board that includes sensors and another exact one that does not include sensors.
Consider a board with the human-readable name DevAcademy L3E1, based on the nRF52833 SoC. The board will have the board name devacademyl3e1, and the board target devacademyl3e1/nrf52833. The board can have an optional revision that can be specified as [email protected]/nrf52833 and it could have an optional variant [email protected]/nrf52833/sense.
Note
The CPU clusters are defined by the SoC layer, and the nRF52833 SoC does not have any clusters.
Location of custom board
Before diving into the board files that make up the custom board definition, we need to know where to put the files.
When working with custom boards, you have three main options for where to place the board definition files. Each option has its own advantages and limitations:
Out-of-Tree (dedicated directory): In this approach, your board files are stored outside of the nRF Connect SDK/Zephyr tree in a separate directory. You’ll configure the build system to locate and use these external board files. This method is ideal for closed-source projects where you want to keep board definitions private. This is the method we’ll focus on in this lesson.
Upstream in Zephyr: Choose this option if you’re developing a development kit, module, reference design, or prototyping platform that you intend to share with the Zephyr community. It’s also appropriate for open-source products. Board definitions submitted upstream must include documentation and go through a review and approval process by the Zephyr maintainers.
Inside the application’s boards folder: This option is suitable for quick prototyping or debugging. You can place the board files directly in a boards subdirectory within your application folder. This is a convenient approach for temporary or experimental work.
Board files
Consider our new development kit DevAcademy L3E1 which is based on the nRF52833 SoC. The board name for this board will be devacademyl3e1.
When creating a custom board definition, remember that the SDK provides the hardware layer files from Architecture up to SoC. So, we only need to populate the board layer. The board layer consists of these four mandatory files.
The term <vendor> serves as a placeholder for the vendor name.
Mandatory files
Let’s take a close look at the four mandatory files in the board layer.
1. board.yml
The board.yml file is a required component introduced in Hardware Model v2 (HWMv2). Each board folder must contain one board.yml, and it serves as a central configuration file that defines key properties for your board.
Board name: Defines the board name or names.
SoC selection: At least one SoC must be specified.
Revisions: Optional; used to define specific hardware versions.
Variants: Used for special configurations, such as enabling TF-M or using a different CPU core.
While it’s technically possible to define multiple boards in one folder using a single board.yml, this is not a common use case.
When you use the extension tool and input the board name, SoC, SoC variant, and vendor, the board.yml file is generated automatically. In most cases, you won’t need to manually edit it.
Here is what a board.yml file typically looks like. You could also include full_name: in board.yml to specify the human-readable name of your board.
Let’s take a look at the board.yml files for some Nordic development kits.
board.yml examples
Single board target: The nRF52840 dongle is based on the nRF52840 SoC, a single-core device with no CPU clusters.
Quad board target: The nRF54L15 has two CPU clusters defined by the SoC layer, cpuapp and cpuflpr. The board.yml defines a new variant, xip, which is associated with cpuflpr. It also defines another variant called ns (TF-M enabled) associated with the cpuapp. So in total, there are 4 board targets.
Dual board target with revisions: The nRF9161 DK has no CPU clusters defined by the nRF9161 SiP. There is a variant, ns. It also defines two revisions: 0.9.0 (default) and 0.7.0.
2. Kconfig.devacademyl3e1
This file serves a specific and essential purpose: it selects the SoC(s) used by the board. By doing so, it pulls in the appropriate hardware layer files from Architecture up to SoC. It also defines a Kconfig symbol for the board, which is the board name prefixed with BOARD_ .
It contains select statement(s)
Only selectis needed for a single-board target
select … if statements are needed for multi-core SoCs or multi-SoC boards
Here are some examples:
Below is an example of our devacademyl3e1 (single board target) that we will develop in Exercise 1, which is based on the nRF52833 QIAA.
Copy
configBOARD_DEVACADEMYL3E1selectSOC_NRF52833_QIAA
Here is another example for the nRF54L15 DK (quad board target). The file selects the appropriate SoC support layer based on the normalized board target triggered from the build system.
3. devacademyl3e1.dts
The board-level devicetree file is a hardware description written in the devicetree format. It represents the schematics of your board, detailing its physical components and connections.
It includes connectors and any other hardware components such as LEDs, buttons, sensors, or communication peripherals (USB, BLE controller, etc). Memory partitioning is also done in this file. We will rely heavily on the automation provided by the nRF Connect for VS Code extension, including the Devicetree Visual Editor, to help us populate this file.
If your board has multiple board qualifiers (i.e., different board targets or variants), you need to create a separate board-level devicetree file for each board target. You can structure the board-level devicetree file into multiple files to improve readability and maintainability.
4. devacademyl3e1-pinctrl.dtsi
This file defines the pin-mapping of your board’s peripherals.
If your board has multiple board qualifiers (i.e., different board targets or variants), you need to create a separate pin-mapping file for each board target.
Optional files
Now that we’ve covered the four mandatory files in the board layer, let’s take a look at the optional files.
Below is a board layer consisting of all mandatory files, optional, and special use cases files:
Copy
boards/<vendor>/devacademyl3e1├── board.yml├── Kconfig.devacademyl3e1├── devacademyl3e1_<qualifiers>.dts ├── devacademyl3e1_<qualifiers>-pinctrl.dtsi├── devacademyl3e1_<qualifiers>_defconfig├── Kconfig.defconfig├── board.cmake # Used for flash and debug├── CMakeLists.txt # Needed in special cases ├── c_files.c # Needed in special cases├── doc # Optional │ ├── devacademyl3e1.png│ └── index.rst├── Kconfig # Optional to create a board Kconfig options menu├── devacademyl3e1_<qualifiers>.yml # Optional for Test Runner (Twister)├── devacademyl3e1_<qualifiers>_<revision>.conf # Needed to support hardware revisions├── devacademyl3e1_<qualifiers>_<revision>.overlay #Needed to support hardware revisions└── dts # Optional └── bindings
The term <vendor> serves as a placeholder for the vendor name. If the board has qualifiers (<qualifiers>), such as multiple SoCs, CPU clusters, or variants (e.g., multi-board target), these qualifiers must be appended to the board name to clearly indicate where you want these files to apply.
devacademyl3e1_defconfig
The devacademyl3e1_defconfig file is a Kconfig fragment that is merged as-is into the final build of any application built for the specified board.
Here is the default devacademyl3e1_defconfig file generated by the tool (differs from one SoC to another).
In addition to the default Kconfig symbols, we need to manually include any additional Kconfig symbols that we want to be enabled for all applications built for the board.
In the case of our board, DevAcademy L3E1, it’s a development kit, so we want to add UART, RTT and GPIO support. Therefore, we will append the following:
<boardname>_defconfig is a Kconfig fragment merged as-is into the final build of any application built for the specified board, and must enable the bare minimum. It’s the application configuration’s (prj.conf) responsibility to configure what is needed.
If your board has multiple board qualifiers (i.e., different board targets or variants), you need to specify the qualifiers in the name of the file (e.g., devacademyl3e1_<qualifiers>_defconfig) for it to take effect when a certain qualifier is passed to the build system.
Kconfig.defconfig
The Kconfig.defconfig file defines board-specific default values for Kconfig options. The content of this file is wrapped in if /endif blocks that correspond to specific board targets. This file is automatically generated by the tool and complements the defconfig file by setting defaults that only apply when building for a particular board.
Let’s see the example for our board which has a single board target devacademyl3e1/nrf52833.
The CONFIG_BT_CTLR Kconfig option, which enables support for the SoC native Bluetooth LE controller implementation, is only enabled if CONFIG_BT is selected by the application.
If the board has multiple board targets, you can have multiple if/endif blocks for the different board targets.
For example, in the Kconfig.defconfig file for the nRF54L15 DK.
CMakeLists.txt: Used to include source files that should be executed pre- or post-kernel. For example, if your hardware requires custom mux configurations or needs to be configured in a particular way, it can be added to this file. This is done for the nRF52840 Dongle where board_nrf52840dongle_nrf52840_init()is executed at PRE_KERNEL_1 before the kernel. Note that the extension does not create the CMakeLists.txt file; you need to manually create it if needed.
doc/index.rst,doc/devacademyl3e1.png: Documentation and image of the board, only needed if you are Contributing your board to Zephyr.
Kconfig: Allows you to create a custom Kconfig menu specific to your board.
devacademyl3e1.yml: A YAML file with miscellaneous metadata used by Zephyr’s Test Runner (Twister). If your board has multiple qualifiers, you need to have a .yml for each.
Board revisions
When you create new hardware revisions for your board, such as changes to the schematics or a new PCB layout, you do not need to create a completely new board definition. Instead, you can simply add the revision-specific files within the same board folder, devacademyl3e1_<revision>.conf and devacademyl3e1_<revision>.overlay, and update board.yml to include the revision.
Keep in mind that if your board has multiple board qualifiers, you need to specify the .conf and .overlay files to the affected qualifiers, e.g., devacademyl3e1_<qualifiers>_<revision>.conf, devacademyl3e1_<qualifiers>_<revision>.overlay.
devacademyl3e1_<revision>.conf: The optional Kconfig settings specified here will be merged into the board’s default Kconfig configuration.
devacademyl3e1_<revision>.overlay: The optional devicetree overlay will be overlayed with the board-level devacademyl3e1.dts devicetree file.
board.yml: The revision: property controls how the Zephyr build system matches the <board_name>@<revision> string specified by the user when building an application for the board.
Note
When creating a new custom board, it is always a good idea to start looking into the SDK-defined boards with the same SoC/SiP as your custom board for inspiration. There is a long list of Development Kits, Prototyping Platforms, and Reference designs already shipped in the SDK that can serve as a good starting point.
They are available in two locations <install_path>/zephyr/boards/nordic/ and <install_path>/nrf/boards/nordic/
This lesson covers how to define boards in the nRF Connect SDK using both hardware models v1 and v2 (HWMv1 and HWMv2 respectively).
This exercise tab is for nRF Connect SDK v2.6.2 – v2.5.2, where HWMv1 is used. HWMv1 is deprecated and removed in nRF Connect SDK v3.0.0. We recommend using HWMv2 for all new designs (other tabs).
In this topic, we will explore the different options for creating custom board files and the guidelines for naming your custom board. You can watch the video below or read the lesson text.
We will cover the mandatory and optional files required to define a custom board, as well as how to create a revision of the board. We will study these files one by one and understand their role.
In Exercise 1 of this lesson, we will use the Create a new board GUI in the nRF Connect for VS Code extension to define a new board, and populate most of the mandatory files’ content.
Naming your custom board
When naming your custom board, there are some conventions that you need to follow.
You need to give your board a unique name. Run west boards in the nRF Connect Terminal for a list of names that have already been taken; you can’t name your custom board with a name that is already in use.
It’s recommended that your board name include the name of the SoC at the end. For instance, suppose we want to make a new board called DevAcademy, which is based on the nRF52833 SoC. It’s highly recommended that you call your board “DevAcademy nRF52833”.
Note that the Create a new board GUI in nRF Connect for VS Code extension will ask you to provide a human-readable name for your board (e.g., DevAcademy nRF52833), and it will automatically generate the board name (devacademy_nrf52833).
Definition
Human-readable name (full_name) is the descriptive name for the board, which can include spaces and capital letters. The full name is intended for display purposes and documentation, making it easier for users to recognize the board.
Board name is typically a lowercase, underscore-separated version of the human-readable name, with all whitespaces replaced by underscores. The board name uniquely and descriptively identifies a particular system, but does not include additional information that may be required to actually build an image.
Location of custom board
Before diving into the board files that make up the custom board definition, we need to know where to put the files.
When working with custom boards, you have three main options for where to place the board definition files. Each option has its own advantages and limitations:
Out-of-Tree (dedicated directory): In this approach, your board files are stored outside of the nRF Connect SDK/Zephyr tree in a separate directory. You’ll configure the build system to locate and use these external board files. This method is ideal for closed-source projects where you want to keep board definitions private. This is the method we’ll focus on in this lesson.
Upstream in Zephyr: Choose this option if you’re developing a development kit, module, reference design, or prototyping platform that you intend to share with the Zephyr community. It’s also appropriate for open-source products. Board definitions submitted upstream must include documentation and go through a review and approval process by the Zephyr maintainers.
Inside the application’s boards folder: This option is suitable for quick prototyping or debugging. You can place the board files directly in a boards subdirectory within your application folder. This is a convenient approach for temporary or experimental work.
Board files
Consider our new development kit DevAcademy nRF52833, which is based on the nRF52833 SoC. The board name generated for this board will be devacademy_nrf52833.
When creating a custom board definition, remember that the SDK provides the hardware layer files from Architecture up to SoC. So, we only need to populate the board layer. The board layer consists of these five mandatory files.
The term <ARCH> serves as a placeholder for the architecture. The extension will automatically populate this with the architecture used by the SoC, as we will see in exercise 1.
Mandatory files
Let’s take a close look at the five mandatory files in the board layer.
1. Kconfig.board
The Kconfig.board file is automatically generated by the extension, and we typically don’t need to change anything inside it. This file defines a Kconfig symbol for your board BOARD_DEVACADEMY_NRF52833 and it specifies a dependency to the SoC hardware support layer (through the depends on keyword).
The Kconfig.defconfig file defines board-specific default values for Kconfig options. The extension automatically generates this file, and we typically don’t need to change anything inside it.
The content of this file is wrapped in if /endif blocks that correspond to specific board targets, as shown below.
When the developer passes the selected target board, BOARD_DEVACADEMY_NRF52833 is set, along with CONFIG_BOARD. The CONFIG_BT_CTLR Kconfig option, which enables support for the SoC native Bluetooth LE controller implementation, is only enabled if CONFIG_BT is selected by the application. This is added here because the nRF52833 SoC is widely used for Bluetooth LE applications.
The devacademyl3e1_nrf52833_defconfig file is a Kconfig fragment that is merged as-is into the final build of any application built for the specified board.
The default Kconfig symbols that are generated by the extension are:
Series hardware support, in the case of the nRF52833 SoC, this is CONFIG_SOC_SERIES_NRF52X , which will enable the CPU and architecture support.
SoC hardware support, CONFIG_SOC_NRF52833_QIAA
Board hardware support
MPU, if the hardware supports it.
Below is the default devacademy_nrf52833_defconfig file generated by the tool.
In addition to the default Kconfig symbols, we need to manually include any additional Kconfig symbols that we want to be enabled for all applications built for the board.
In the case of our board, DevAcademy nRF52833, it’s a development kit, so we want to add UART, RTT and GPIO support. Therefore, we will append the following:
<boardname>_defconfig is a Kconfig fragment merged as-is into the final build of any application built for the specified board, and must enable the bare minimum. It’s the application configuration’s (prj.conf) responsibility to configure what is needed.
4. devacademy_nrf52833.dts
The board-level devicetree file is a hardware description written in the devicetree format. It represents the schematics of your board, detailing its physical components and connections.
It includes connectors and any other hardware components such as LEDs, buttons, sensors, or communication peripherals (USB, BLE controller, etc). Memory partitioning is also done in this file. We will rely heavily on the automation provided by the nRF Connect for VS Code extension, including the Devicetree Visual Editor, to help us populate this file.
5. devacademy_nrf52833-pinctrl.dtsi
This file defines the pin-mapping of your board’s peripherals.
The extension does not create this file, so we must create it ourselves, which we will learn in Exercise 1 of this lesson.
Optional files
Now that we’ve covered the five mandatory files in the board layer, let’s take a look at the optional files.
Below is a board layer consisting of all mandatory files, optional, and special use cases files:
Copy
boards/<ARCH>/devacademy_nrf52833├── Kconfig.board ├── Kconfig.defconfig ├── devacademy_nrf52833_defconfig├── devacademy_nrf52833.dts ├── devacademy_nrf52833-pinctrl.dtsi├── board.cmake # Used for flash and debug├── CMakeLists.txt # Needed in special cases ├── c_files.c # Needed in special cases├── doc # Optional │ ├── devacademy_nrf52833.png│ └── index.rst├── Kconfig # Optional to create a board Kconfig options menu├── devacademy_nrf52833.yaml # Optional for Test Runner (Twister)├── devacademy_nrf52833_<revision>.conf # Needed to support multiple hardware revisions├── devacademy_nrf52833_<revision>.overlay # Needed to support multiple hardware revisions└── revision.cmake # Needed to support multiple hardware revisions└── dts # Optional └── bindings
CMakeLists.txt: Used to include source files to be executed pre- or post-kernel. For example, if your hardware requires custom mux configurations or needs to be configured in a particular way, it can be added to this file. This is done for the nRF52840 Dongle where board_nrf52840dongle_nrf52840_init()is executed at PRE_KERNEL_1 before the kernel. Note that the extension does not create the CMakeLists.txt file; you need to manually create it if needed.
doc/index.rst, doc/devacademy_nrf52833.png: Documentation and image of the board, only needed if you are Contributing your board to Zephyr.
Kconfig: Allows you to create a custom Kconfig menu specific to your board.
devacademy_nrf52833.yaml: A YAML file with miscellaneous metadata used by Zephyr’s Test Runner (Twister).
Board revisions
When you create new hardware revisions for your board, such as changes to the schematics or a new PCB layout, you do not need to create a completely new board definition. Instead, you can simply add the revision-specific files within the same board folder: devacademy_nrf52833_<revision>.conf, devacademy_nrf52833_<revision>.overlay and revision.cmake
devacademy_nrf52833_<revision>.conf: The optional Kconfig settings specified here will be merged into the board’s default Kconfig configuration.
devacademy_nrf52833_<revision>.overlay: The optional devicetree overlay will be added to the common devacademy_nrf52833.dts devicetree file.
revision.cmake: Controls how the Zephyr build system matches the <board>@<revision> string specified by the user when building an application for the board.
Note
When creating a new custom board, it is always a good idea to start looking into the SDK-defined boards with the same SoC/SiP as your custom board for inspiration. There is a long list of Development Kits, Prototyping Platforms, and Reference designs already shipped in the SDK that can serve as a good starting point.
They are available in two locations <install_path>/zephyr/boards/nordic/ and <install_path>/nrf/boards/nordic/
In this Privacy Policy you will find information on Nordic Semiconductor ASA (“Nordic Semiconductor”) processes your personal data when you use the Nordic Developer Academy.
References to “we” and “us” in this document refers to Nordic Semiconductor.
2. Our processing of personal data when you use the Nordic Developer Academy
2.1 Nordic Developer Academy
Nordic Semiconductor processes personal data in order to provide you with the features and functionality of the Nordic Developer Academy. Creating a user account is optional, but required if you want to track you progress and view your completed courses and obtained certificates. If you choose to create a user account, we will process the following categories of personal data:
Email
Name
Password (encrypted)
Course progression (e.g. which course you have completely or partly completed)
Certificate information, which consists of name of completed course and the validity of the certificate
Course results
During your use of the Nordic Developer Academy, you may also be asked if you want to provide feedback. If you choose to respond to any such surveys, we will also process the personal data in your responses in that survey.
The legal basis for this processing is GDPR article 6 (1) b. The processing is necessary for Nordic Semiconductor to provide the Nordic Developer Academy under the Terms of Service.
2.2 Analytics
If you consent to analytics, Nordic Semiconductor will use Google Analytics to obtain statistics about how the Nordic Developer Academy is used. This includes collecting information on for example what pages are viewed, the duration of the visit, the way in which the pages are maneuvered, what links are clicked, technical information about your equipment. The information is used to learn how Nordic Developer Academy is used and how the user experience can be further developed.
2.2 Newsletter
You can consent to receive newsletters from Nordic from within the Nordic Developer Academy. How your personal data is processed when you sign up for our newsletters is described in the Nordic Semiconductor Privacy Policy.
3. Retention period
We will store your personal data for as long you use the Nordic Developer Academy. If our systems register that you have not used your account for 36 months, your account will be deleted.
4. Additional information
Additional information on how we process personal data can be found in the Nordic Semiconductor Privacy Policy and Cookie Policy.
Nordic Developer Academy Terms of Service
1. Introduction
These terms and conditions (“Terms of Use”) apply to the use of the Nordic Developer Academy, provided by Nordic Semiconductor ASA, org. nr. 966 011 726, a public limited liability company registered in Norway (“Nordic Semiconductor”).
Nordic Developer Academy allows the user to take technical courses related to Nordic Semiconductor products, software and services, and obtain a certificate certifying completion of these courses. By completing the registration process for the Nordic Developer Academy, you are agreeing to be bound by these Terms of Use.
These Terms of Use are applicable as long as you have a user account giving you access to Nordic Developer Academy.
2. Access to and use of Nordic Developer Academy
Upon acceptance of these Terms of Use you are granted a non-exclusive right of access to, and use of Nordic Developer Academy, as it is provided to you at any time. Nordic Semiconductor provides Nordic Developer Academy to you free of charge, subject to the provisions of these Terms of Use and the Nordic Developer Academy Privacy Policy.
To access select features of Nordic Developer Academy, you need to create a user account. You are solely responsible for the security associated with your user account, including always keeping your login details safe.
You will able to receive an electronic certificate from Nordic Developer Academy upon completion of courses. By issuing you such a certificate, Nordic Semiconductor certifies that you have completed the applicable course, but does not provide any further warrants or endorsements for any particular skills or professional qualifications.
Nordic Semiconductor will continuously develop Nordic Developer Academy with new features and functionality, but reserves the right to remove or alter any existing functions without notice.
3. Acceptable use
You undertake that you will use Nordic Developer Academy in accordance with applicable law and regulations, and in accordance with these Terms of Use. You must not modify, adapt, or hack Nordic Developer Academy or modify another website so as to falsely imply that it is associated with Nordic Developer Academy, Nordic Semiconductor, or any other Nordic Semiconductor product, software or service.
You agree not to reproduce, duplicate, copy, sell, resell or in any other way exploit any portion of Nordic Developer Academy, use of Nordic Developer Academy, or access to Nordic Developer Academy without the express written permission by Nordic Semiconductor. You must not upload, post, host, or transmit unsolicited email, SMS, or \”spam\” messages.
You are responsible for ensuring that the information you post and the content you share does not;
contain false, misleading or otherwise erroneous information
infringe someone else’s copyrights or other intellectual property rights
contain sensitive personal data or
contain information that might be received as offensive or insulting.
Such information may be removed without prior notice.
Nordic Semiconductor reserves the right to at any time determine whether a use of Nordic Developer Academy is in violation of its requirements for acceptable use.
Violation of the at any time applicable requirements for acceptable use may result in termination of your account. We will take reasonable steps to notify you and state the reason for termination in such cases.
4. Routines for planned maintenance
Certain types of maintenance may imply a stop or reduction in availability of Nordic Developer Academy. Nordic Semiconductor does not warrant any level of service availability but will provide its best effort to limit the impact of any planned maintenance on the availability of Nordic Developer Academy.
5. Intellectual property rights
Nordic Semiconductor retains all rights to all elements of Nordic Developer Academy. This includes, but is not limited to, the concept, design, trademarks, know-how, trade secrets, copyrights and all other intellectual property rights.
Nordic Semiconductor receives all rights to all content uploaded or created in Nordic Developer Academy. You do not receive any license or usage rights to Nordic Developer Academy beyond what is explicitly stated in this Agreement.
6. Liability and damages
Nothing within these Terms of Use is intended to limit your statutory data privacy rights as a data subject, as described in the Nordic Developer Academy Privacy Policy. You acknowledge that errors might occur from time to time and waive any right to claim for compensation as a result of errors in Nordic Developer Academy. When an error occurs, you shall notify Nordic Semiconductor of the error and provide a description of the error situation.
You agree to indemnify Nordic Semiconductor for any loss, including indirect loss, arising out of or in connection with your use of Nordic Developer Academy or violations of these Terms of Use. Nordic Semiconductor shall not be held liable for, and does not warrant that (i) Nordic Developer Academy will meet your specific requirements, (ii) Nordic Developer Academy will be uninterrupted, timely, secure, or error-free, (iii) the results that may be obtained from the use of Nordic Developer Academy will be accurate or reliable, (iv) the quality of any products, services, information, or other material purchased or obtained by you through Nordic Developer Academy will meet your expectations, or that (v) any errors in Nordic Developer Academy will be corrected.
You accept that this is a service provided to you without any payment and hence you accept that Nordic Semiconductor will not be held responsible, or liable, for any breaches of these Terms of Use or any loss connected to your use of Nordic Developer Academy. Unless otherwise follows from mandatory law, Nordic Semiconductor will not accept any such responsibility or liability.
7. Change of terms
Nordic Semiconductor may update and change the Terms of Use from time to time. Nordic Semiconductor will seek to notify you about significant changes before such changes come into force and give you a possibility to evaluate the effects of proposed changes. Continued use of Nordic Developer Academy after any such changes shall constitute your acceptance of such changes. You can review the current version of the Terms of Use at any time at https://academy.nordicsemi.com/terms-of-service/
8. Transfer of rights
Nordic Semiconductor is entitled to transfer its rights and obligation pursuant to these Terms of Use to a third party as part of a merger or acquisition process, or as a result of other organizational changes.
9. Third Party Services
To the extent Nordic Developer Academy facilitates access to services provided by a third party, you agree to comply with the terms governing such third party services. Nordic Semiconductor shall not be held liable for any errors, omissions, inaccuracies, etc. related to such third party services.
10. Dispute resolution
The Terms of Use and any other legally binding agreement between yourself and Nordic Semiconductor shall be subject to Norwegian law and Norwegian courts’ exclusive jurisdiction.