New board extensions not supported by VSCode nRF extension?

RE: New board extensions not supported by VSCode nRF extension?

pcspets — Wed, 25 Mar 2026 16:09:03 GMT

And, with the help of AI, I also managed to solve the problem how to include base board DTS files from extended board conf without needing to patch Zephyr source tree. The key here is to create the following file with the following content. I'm not sure how it works but it works! Now sysbuild with MCUBoot and application target builds fine. Put your app target name in place of [main target name].

[project root]/sysbuild/CMakeLists.txt

cmake_minimum_required(VERSION 3.20.0)

get_filename_component(APP_ROOT "${CMAKE_CURRENT_LIST_DIR}/.." REALPATH)
file(TO_CMAKE_PATH "$ENV{ZEPHYR_BASE}/boards" ZEPHYR_BOARDS_DIR)

list(APPEND BOARD_ROOT ${APP_ROOT})

# Extended boards in this project include upstream board DTS files directly.
# Export the extra include path through the main target image cache so the
# flag reaches the image configure step, not just sysbuild's own scope.
set([main target name]_DTS_EXTRA_CPPFLAGS
"-isystem${ZEPHYR_BOARDS_DIR}"
CACHE INTERNAL "Extra DTS preprocessor flags for the main target image"
)

find_package(Sysbuild REQUIRED HINTS $ENV{ZEPHYR_BASE})
project(sysbuild LANGUAGES)

RE: New board extensions not supported by VSCode nRF extension?

pcspets — Sat, 21 Mar 2026 10:47:34 GMT

Unbelievable but I managed to fix everything with AI that made patched to the VSCode nRF Connect Extension minified *.js files. I asked her to to write a small report about the problems and solutions:

# HWMv2 extended-board issues in VS Code: three final fixes

Environment:

- NCS `v3.2.1`

- `nordic-semiconductor.nrf-connect-2026.3.1585`

- `nordic-semiconductor.nrf-devicetree-2026.3.617`

- correct HWMv2 board-extension syntax, for example:

```yaml

board:

extend: nrf9160dk

variants:

- name: overseer

qualifier: nrf9160/ns

```

We had three extension-side problems with correctly defined HWMv2 extended boards such as `nrf9160dk/nrf9160/ns/overseer` and `nrf9151dk/nrf9151/ns/overseer`.

## 1. `Add Build Configuration` hung when the extended board used the correct multi-segment qualifier

Root cause:

`nrf-connect` did not merge HWMv2 board extensions correctly when the variant was defined as `name: overseer` and the qualifier was a multi-segment path such as `nrf9160/ns` or `nrf9151/ns`.

What had to be changed in the Nordic extension source:

- In `nrf-connect`, the HWMv2 board-extension merge routine had to be changed so the existing qualifier chain is matched first, and only then the new variant name is appended.

- In practice, that means `qualifier: nrf9160/ns` + `name: overseer` must resolve as `nrf9160/ns/overseer`, instead of being treated like an unmatched or flattened variant.

- The same board-resolution path also had to stop assuming a single base-board `directory`; merged HWMv2 metadata had to respect all board directories exposed by the resolved board.

After that change, `Add Build Configuration` opened normally and could create valid build configs for the extended board.

## 2. Debug session could not be started for the extended board

Root cause:

The debug flow in `nrf-connect` depended on the same incorrect HWMv2 board resolution path as the build-config UI. When the board extension was not resolved correctly, the active build/debug context for the extended board was also wrong.

What had to be changed in the Nordic extension source:

- The same `nrf-connect` HWMv2 merge fix from issue 1 had to be applied to the board-resolution path used by build target activation and debug actions.

- Once the extension resolved the board as the real extended target, the debug session could bind to the correct build context instead of failing on the unresolved board variant.

Note:

In our project, debug also required project-side `board.cmake` files for the `*_OVERSEER` board symbols so Zephyr generated `runners.yaml`. That part is outside the extension, but the extension-side board-resolution fix was still required before debug worked reliably.

## 3. DeviceTree Visual Editor could not be opened or had the wrong/empty context

Root cause:

This was a combination of command registration, board identification, include-path handling, and file-to-context matching problems between `nrf-connect` and `nrf-devicetree`.

What had to be changed in the Nordic extension source:

- In `nrf-devicetree`, activation had to continue even when `nrf-connect` is installed. Otherwise `devicetree.showVisualEditor` was never registered.

- In `nrf-connect`, the Devicetree context passed to `nrf-devicetree` had to include the resolved `boardInfo` from the build, instead of forcing `nrf-devicetree` to derive the HWMv2 board identity again from the base-board path.

- In `nrf-connect`, the include-path list for the Devicetree context had to be extended with both the resolved board directories and their parent `boards` roots. Without that, includes such as `#include <nordic/nrf9160dk/nrf9160dk_nrf9160_ns.dts>` were not resolved correctly in the Visual Editor.

- In `nrf-devicetree`, file/context matching had to use canonical-path comparison (`realpath`) and parser lookup by file URI. This was required because the workspace is opened through a junction path, while build metadata resolves the real path.

After those changes, the Visual Editor could be opened, it recognized the file as part of the active build context, and it loaded both the custom-board and base-board DTS content correctly.

RE: New board extensions not supported by VSCode nRF extension?

pcspets — Tue, 10 Mar 2026 14:26:43 GMT

Well, yeah, That is the problem still not solved, that was discussed earlier in this thread. A quick and simple work-around is to add the line:

list(APPEND DTS_EXTRA_CPPFLAGS "-isystem$ENV{ZEPHYR_BASE}/boards/")

...to the original board "pre_dt_board.cmake" file, in Zephyr source tree.

RE: New board extensions not supported by VSCode nRF extension?

Kazi Afroza Sultana — Tue, 10 Mar 2026 13:52:10 GMT

Hello,

I have looked at your application folder and also run the sample on NCS V3.2.0. Your board file is incomplete.

It does not look like a proper board file.

The error shows

You mentioned earlier that ''It's not the build that fails. It's the VSCode nRF Extension that cannot start debug session. And it cannot show graphical representation of DeviceTree either.'' Can you send me the application folder which you were able to build?

RE: New board extensions not supported by VSCode nRF extension?

pcspets — Wed, 04 Mar 2026 15:17:48 GMT

It's not the build that fails. It's the VSCode nRF Extension that cannot start debug session. And it cannot show graphical representation of DeviceTree either.

RE: New board extensions not supported by VSCode nRF extension?

Kazi Afroza Sultana — Wed, 04 Mar 2026 07:25:46 GMT

Hello,

Sorry for the late reply. Do you still have the issue?

VSCode shows the extended board. if west build fails then it is the build system or the application from that is the issue. However, have you tried to install latest VSCode extension?

RE: New board extensions not supported by VSCode nRF extension?

pcspets — Thu, 15 Jan 2026 15:05:01 GMT

As can be seen in the example that I provided, the extended board name is "adafruit_feather_nrf52840/nrf52840/test". And it can be reprocuced with a standard sysbuild build process.

RE: New board extensions not supported by VSCode nRF extension?

Kazi Afroza Sultana — Mon, 05 Jan 2026 13:18:05 GMT

Hello,

Can you show the build process on VSCode and also west? What is the board name you used for building the application?

RE: New board extensions not supported by VSCode nRF extension?

pcspets — Mon, 15 Dec 2025 13:12:08 GMT

Couldn't find a good way how to define this include for MCUboot - so I finally decided to quick-temp-patch Zephyr and added

list(APPEND DTS_EXTRA_CPPFLAGS "-isystem$ENV{ZEPHYR_BASE}/boards")

to the correcponding board "pre_dt_board.cmake" in the Zephyr source tree.

But there is one more bug still. Debugging doesn't work if original board has already qualifiers. VSCode gives the following error message:

Invalid identifier for board 
file:///c%3A/ncs/v3.2.0/zephyr/boards/adafruit/feather_nrf52840

It can be easily reproduced with the following sample project:

devzone.nordicsemi.com/.../extended_5F00_board_5F00_test_5F00_debug_5F00_fail_5F00_if_5F00_more_5F00_qualifiers.zip

This Adafruit board is a bit wrongly named ("nrf52840" is in the board name and second "nrf52840" is probably already treated as extra qualifier), but it doesn't matter, the same error comes when extending nRF91 *_ns board, for example.

RE: New board extensions not supported by VSCode nRF extension?

Kazi Afroza Sultana — Mon, 08 Sep 2025 14:03:11 GMT

Hello Lauri,

You may look at this Sysbuild (System build) documentation for both west and cmake.

RE: New board extensions not supported by VSCode nRF extension?

pcspets — Tue, 26 Aug 2025 06:43:00 GMT

Hello

Thank you, I almost got it working. Now the only trouble is that I cannot find a way how to set this variable for MCUBoot when using sysbuild. Do you have any idea?

Lauri

RE: New board extensions not supported by VSCode nRF extension?

Sigurd — Thu, 31 Jul 2025 09:10:56 GMT

Hi! Kazi is out of office, so I'm replying instead.

The CMake variable DTS_EXTRA_CPPFLAGS can be used to add more include paths, such as:
-isystem${ZEPHYR_BASE}/boards/nordic/nrf52840dk

The ideal place to set this variable would be pre_dt_board.cmake in the board extension directory. However, Zephyr doesn't source this file for board extensions. We have submitted a fix, but it needs more work before it's accepted: https://github.com/zephyrproject-rtos/zephyr/pull/87821

Alternatively, DTS_EXTRA_CPPFLAGS can be set like any other CMake variable, e.g. before find_package(Zephyr) or on command-line. It's also one of the few variables allowed in snippets.

RE: New board extensions not supported by VSCode nRF extension?

pcspets — Mon, 28 Jul 2025 08:14:18 GMT

Hello

Have you had any reply from the team?

Lauri

RE: New board extensions not supported by VSCode nRF extension?

Kazi Afroza Sultana — Tue, 25 Mar 2025 09:22:19 GMT

I talked to team and will get back to you soon.

RE: New board extensions not supported by VSCode nRF extension?

pcspets — Wed, 19 Mar 2025 07:14:08 GMT

Indeed, that did the trick. This is not documented.

But now there is another problem. I would like my "nrf52840dk_nrf52840_test.dts" to be an extendsion to

"boards/nordic/nrf52840dk_nrf52840/nrf52840dk_nrf52840.dts". Seems that it is not automatically and however I try, I cannot #include it either. Your example board makes #include only to the base files.

RE: New board extensions not supported by VSCode nRF extension?

Kazi Afroza Sultana — Wed, 19 Mar 2025 05:56:35 GMT

Hello,

You need to add extension in your kconfig for board file.

config BOARD_NRF52840DK
select SOC_NRF52840_QIAA if BOARD_NRF52840DK_NRF52840_MY_EXTENSION

In your case it is ''test'

I have added the modified folder of the application, and you can try to run this.

devzone.nordicsemi.com/.../nrf52840dk_5F00_test.zip

RE: New board extensions not supported by VSCode nRF extension?

pcspets — Fri, 14 Mar 2025 14:32:21 GMT

Yes, I still have the issue.

Are you sure you selected "nrf52840dk/nrf52840/test" as your board target?

RE: New board extensions not supported by VSCode nRF extension?

Kazi Afroza Sultana — Fri, 14 Mar 2025 14:21:22 GMT

hello,

Do you still have the issue?

I have run your project on nRF52840 DK on NCS version 2.9.0. It built ok.

RE: New board extensions not supported by VSCode nRF extension?

pcspets — Fri, 24 Jan 2025 08:56:46 GMT

These versions that I listed in this thread two months ago, it was before the fix. I definitely updated the plugins and tried with new versions.

To be sure, I tested it again.

I have the following versions now:
-/
nRF Connect for VS Code Extension Pack
v2024.9.5

nRF Connect for VS Code
v2025.1.127

nRF DeviceTree
v2024.12.15

nRF Kconfig
v2024.12.13

nRF Terminal
v2024.9.14

nRF Connect SDK
v2.9.0
/-

And my sample project still fails exatcly the same as described before.

RE: New board extensions not supported by VSCode nRF extension?

Kazi Afroza Sultana — Fri, 24 Jan 2025 08:43:25 GMT

Hello,

I talked to team and got the following feedback.

Board extends was added to the version 2024.12.55. User is using an old version.

You can try to update it to latest. It should work.

RE: New board extensions not supported by VSCode nRF extension?

pcspets — Thu, 09 Jan 2025 12:16:29 GMT

Yes, I believe I select the board name correctly:

And when CMake runs, it states:

-- Board: nrf52840dk, qualifiers: nrf52840/test

And then after fails with the error message:

CMake Error at C:/ncs/v2.9.0/zephyr/cmake/modules/arch_v2.cmake:36 (message):
  ARCH not defined.  Check that BOARD=nrf52840dk, is selecting an appropriate
  SoC in Kconfig, SoC=, and that the SoC is selecting the correct
  architecture.

Try it with the attached sample project:

devzone.nordicsemi.com/.../extended_5F00_board_5F00_test_2D00_compile_2D00_failure.zip

It is just an empty (with no modifications) extension for a nrf52840dk.

RE: New board extensions not supported by VSCode nRF extension?

Kazi Afroza Sultana — Mon, 06 Jan 2025 16:59:34 GMT

Hello,

Did you select the board name correctly? Is it a custom board?

RE: New board extensions not supported by VSCode nRF extension?

pcspets — Fri, 20 Dec 2024 08:25:11 GMT

The support has arrived - thank you! But for some reason it fails to compile with the following CMake error:

  ARCH not defined.  Check that BOARD=nrf52840dk, is selecting an appropriate
  SoC in Kconfig, SoC=, and that the SoC is selecting the correct
  architecture.

Am I doing something wrong?

PS. The sample project needs one fix before compiling - "nrf52840dk_nrf52840dk_test.dts" needs the following mandatory content:

/dts-v1/;

/ {
};

RE: New board extensions not supported by VSCode nRF extension?

Kazi Afroza Sultana — Mon, 09 Dec 2024 07:45:30 GMT

You are welcome, Lauri. :)

RE: New board extensions not supported by VSCode nRF extension?

pcspets — Wed, 04 Dec 2024 13:32:46 GMT

Hello

Thank you very much and glad to hear that!

Regards

Lauri