Feedback Request: Self-Contained NCS Local SDK/Toolchain

Hi,
We’re trying to develop a way to create fully self-contained repositories that include:

-the toolchain

-the entire SDK

-the necessary tools (for example, flashing tools (i.e., nrfutil-device))

Anyone downloading the repository should have everything they need, without requiring any additional system-level tool installations.

You can download our template-repo directly form here ( as .zip)www.dropbox.com/.../fw-rain-gamma_ld-nrfc-sdk.zip

Development is on Windows 11 using VS Code with the Nordic extension.

The repository is dowloaded using git (not west) since west is in the toolchain path itself of the repo.

The repo structure is similar to y the official one: https://github.com/nrfconnect/ncs-example-application.  The main diffrence is that our repo could contain multiple applictations.

I’m attaching the repo we’ve developed so far, and here are the steps to set it up:

  1. Double-click the .code-workspace file. This will open VS Code with the settings defined inside it. Inside the file, you’ll find the nrf-connect.nrfutil.home setting.
  2. Create a new PowerShell terminal (Terminal -> New Terminal)
  3. Run ./setup_nrf_connect.ps1: this will install both the toolchain and the SDK locally, using nrfutil located in tools/nrfutil/nrfutil.exe.
  4. Close VS Code
  5. Re-open the .code-workspace file and click on the nRF Connect extension: this should open console_app and detect the locally installed SDK/toolchain.

From your expert point of view — do you think the system we’ve set up is scalable and reliable enough?

Thank you,

Alessandro

Parents
  • Hi Alessandro,

    Is your setup the same as in your other ticket linked below?
    devzone.nordicsemi.com/.../vsc-extension-nrf-connect-nrfutil-home-how-should-be-used
    How do you intend to use nrfutil from your local folder?

    From your expert point of view — do you think the system we’ve set up is scalable and reliable enough?

    What are your future plans with regard to scalability? 
    Do you have any specific concerns regarding reliability? What would be "reliable enough" in your case?

    Best regards,
    Dejan

  • Hi Dejan,

    yes it is similar- the main difference is the presence of zephyr/module.yml which allows to add custom board/driver/library without relying on EXTRA_ZEPHYR_MODULES in CMakeLists.txt of the application.

    My question is on the methodology:

    • If you needed to implement something similar, how would you approach it in a Nordic environment? All the examples I’ve found, including those from the Developer Academy, assume having nrfutil, the SDK, and the toolchain already installed on the system. 
    • Is in your opnion my approach the "right" way?

    Regarding scalability/reliability:

    • Since the SDK/Toolchain and nrfutil (along with its subcommands) are updated quite frequently, I want to maintain full control over them within our repository. We develop many projects under NCS, each with its own SDK, toolchain, and nrfutil version. Managing these at the system level would be messy and impractical for our needs.

    Regarding nrfutil:

    • in folder tools/nrfutil/nerfutil.exe a specific version is commited with the repo.
    • All subcommands are installed there by setting  $env:NRFUTIL_HOME = "tools/nrfutil/.nrfutil"
    • All subcommands are called by setting also $env:NRFUTIL_HOME = "$cwd\tools\nrfutil\.nrfutil", for example here the flash_build.ps1 called by my binding tasks (check the .code-workspace file):
    • param (
          [string]$build_folder,
          [bool] $erase_all = $false
      )
      $cwd = Get-Location
      $nrfutil_command = "$cwd\tools\nrfutil\nrfutil.exe"
      #set the env variable pointing nrfutil install dir
      $env:NRFUTIL_HOME = "$cwd\tools\nrfutil\.nrfutil"
      # program fw
      if($erase_all){
          $erase_option = "chip_erase_mode=ERASE_ALL"
      } else{
          $erase_option = "chip_erase_mode=ERASE_RANGES_TOUCHED_BY_FIRMWARE"
      }
      $nrfutil_program_command = "$nrfutil_command device program  --traits jlink --firmware $build_folder/merged.hex  --options $erase_option,reset=RESET_SYSTEM"
      Invoke-Expression -Command $nrfutil_program_command
Reply
  • Hi Dejan,

    yes it is similar- the main difference is the presence of zephyr/module.yml which allows to add custom board/driver/library without relying on EXTRA_ZEPHYR_MODULES in CMakeLists.txt of the application.

    My question is on the methodology:

    • If you needed to implement something similar, how would you approach it in a Nordic environment? All the examples I’ve found, including those from the Developer Academy, assume having nrfutil, the SDK, and the toolchain already installed on the system. 
    • Is in your opnion my approach the "right" way?

    Regarding scalability/reliability:

    • Since the SDK/Toolchain and nrfutil (along with its subcommands) are updated quite frequently, I want to maintain full control over them within our repository. We develop many projects under NCS, each with its own SDK, toolchain, and nrfutil version. Managing these at the system level would be messy and impractical for our needs.

    Regarding nrfutil:

    • in folder tools/nrfutil/nerfutil.exe a specific version is commited with the repo.
    • All subcommands are installed there by setting  $env:NRFUTIL_HOME = "tools/nrfutil/.nrfutil"
    • All subcommands are called by setting also $env:NRFUTIL_HOME = "$cwd\tools\nrfutil\.nrfutil", for example here the flash_build.ps1 called by my binding tasks (check the .code-workspace file):
    • param (
          [string]$build_folder,
          [bool] $erase_all = $false
      )
      $cwd = Get-Location
      $nrfutil_command = "$cwd\tools\nrfutil\nrfutil.exe"
      #set the env variable pointing nrfutil install dir
      $env:NRFUTIL_HOME = "$cwd\tools\nrfutil\.nrfutil"
      # program fw
      if($erase_all){
          $erase_option = "chip_erase_mode=ERASE_ALL"
      } else{
          $erase_option = "chip_erase_mode=ERASE_RANGES_TOUCHED_BY_FIRMWARE"
      }
      $nrfutil_program_command = "$nrfutil_command device program  --traits jlink --firmware $build_folder/merged.hex  --options $erase_option,reset=RESET_SYSTEM"
      Invoke-Expression -Command $nrfutil_program_command
Children
No Data
Related