Place Nrf Connect SDK in subfolder in west Workspace

[LChesterID]

Hi,

I am currently in the process of setting up the repository structure for a new project that uses two different sdks for different MCU families. 

The main MCU in project is the NRF9160 and I was planning to set up the project to use the west tool and its manifest system to define the project structure from multiple repositories.

The question I have relates to placing the nrf connect sdk (and all its additional repos) into a subfolder within the workspace.

For my project I have 2 user applications: 

1. NRF9160 Main Application

2. Secondary MCU Application

I was hoping to have a final workspace structure like follows where the entire nrf connect sdk is located in "nordic_sdk":

workspace-root
+---.west
|   \---config
+---app1_nrf9160
+---app2
+---manifest_repo
|   \---west.yml
+---nordic_sdk
|   +---bootloader
|   +---modules
|   +---nrf
|   +---nrfxlib
|   +---test
|   +---tools
|   +---zephyr
\---secondary_sdk

While I have been able to get west to produce this file structure using "west init" and "west update", the NRF Connect SDK VS Code extension is unable to locate the nrf sdk and any predefined boards etc. 

From what I have seen in the topologies supported by the nrf connect sdk and zephyr documentations (on this page: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/zephyr/develop/west/workspaces.html#west-topologies)

the nrf connect sdk is always located within the first level of the west workspace. Eg the following format:

workspace-root
+---.west
|   \---config
+---app1_nrf9160
+---app2
+---manifest_repo
|   \---west.yml
+---bootloader
+---modules
+---nrf
+---nrfxlib
+---test
+---tools
+---zephyr
\---secondary_sdk

While this method works for the VS Code extension it makes the folder structure less manageable. Is this a limitation of the west tool? Is it only able to recognize the nrf connect sdk if the folder structure keeps the nrf connect sdk in the top level of the workspace?

The manifest file I have been using is as follows (removing any repo addresses):

manifest:

    remotes:
        - name: workspace-root
          url-base: <base_git_repo_url>

    defaults:
      remote: remote_name

    projects:
        - name: app1_nrf9160
          path: app1_nrf9160
          revision: main
        - name: app2
          path: app2
          revision: main
        - name: secondary_sdk
          repo-path: secondary_sdk
          revision: main
          submodules: true
        - name: nrf
          repo-path: sdk-nrf
          revision: v2.3.0
          import:
            path-prefix: nordic-sdk
          clone-depth: 1
        - name: zephyr
          repo-path: sdk-zephyr
          revision: v3.2.99-ncs2
          import: 
            path-prefix: nordic-sdk
            name-allowlist:
            - TraceRecorderSource
            - canopennode
            - chre
            - cmsis
            - edtt
            - fatfs
            - hal_nordic
            - hal_st # required for ST sensors (unrelated to STM32 MCUs)
            - hal_wurthelektronik
            - liblc3
            - libmetal
            - littlefs
            - loramac-node
            - lvgl
            - lz4
            - mipi-sys-t
            - nanopb
            - net-tools
            - nrf_hw_models
            - open-amp
            - picolibc
            - psa-arch-tests
            - segger
            - tinycbor
            - tinycrypt
            - tf-m-tests
            - uoscore-uedhoc
            - zcbor
            - zscilib
    self:
        path: manifest_repo

Here is the .west/config file also:

[manifest]
path = manifest_repo
file = west.yml

[zephyr]
base = nordic-sdk/zephyr

[update]
sync-submodules = false

I would greatly appreciate some assistance and a definitive answer on this.

Thanks in advance

[Raoul]

Hi,

I believe there are limitations in the VS Code extension on top of limitations that West itself might have. For instance, regarding board detection I came across this statement from the VS Code Extension team:

Currently, the extension only looks for boards in the nrf and zephyr directories, as well as the open VS Code workspace folders and whatever is added to the board roots setting.

I also found the following:

You can set the nrf-connect.topdir setting in your workspace settings if you're working with an application that isn't part of the west workspace. You can change this setting to point to the right version of NCS in the settings view, or use the nRF Connect extension's Welcome page "quick setup" section to browse for other NCS installations.

Could you try changing the nrf-connect.topdir setting to see if your desired topology could work with the extension?

Let me know if that works! I don't have much experience with alternate topologies unfortunately, especially unusual ones like this.

Best regards,

Raoul

[Ars Morozov]

Hello. I have the same problem. 
The problem is that env variable ZEPHYR_BASE is configuring automatically by vsc extension. And it seems it's not possible to override it:
1) it not possible to override via Welcome page, it return "Cannot change active SDK, as the current SDK is part of the VS code workspace"
2) And it not possible to overwrite it via json .settings:

        "nrf-connect.topdir": "${workspaceFolder}/sdk/zephyr",
Extension ignores this setting. When I list env it show that ZEPHYR_BASE links to workspacefolder/zephyr.

It seems that if vsc extenstion detect ".west" folder, it not allow to overwrite nrf-connect.topdir.


Is it possible to resolve this problem?

[Raoul]

Hi,

Sorry for the brief reply, but please see the following two pages and compare them to your configuration:

https://nrfconnect.github.io/vscode-nrf-connect/guides/workspaces.html

https://nrfconnect.github.io/vscode-nrf-connect/guides/extension_settings.html

It might also be necessary to delete your build folder when you make changes.

Best regards,

Raoul