Welcome to the September 2023 release of nRF Connect for VS Code.
This release, we have been working on improving the following areas:
- Toolchain Management
- SDK Management
- Create New Application
- Welcome View
- Applications View
- Details View
- New Build Configuration
- Status Bar
- Create Board
- C/C++ Language support
- Other improvements
Changes in 2023.9.336¶
- Skip querying for nRF Command Line Tools altogether when the notification has been disabled.
- Changed toolchain removal menu to select one at a time to prevent issues with the Toolchain Manager's lockfile.
- Improved startup time by about 30%.
- Added a link to open output window from the progress bar for
- Fixed an issue that would make some native toolchain installations interfere with the nRF Connect Toolchain v2.0-v2.3.
- Fixed false positives with stale build warning:
- No longer triggered by unusual
- No longer shows child images as stale.
- Fixed an issue where the Actions View would be hidden if there was an unused west manifest in the workspace.
- Improved the selection of the active application during builds.
- Added ability to get the J-Link device ID from the
runners.yamlfile to support debugging on any device with a J-Link probe.
- Now hiding the unused configuration file sections for TF-M and sysbuild configurations.
- Added the option to browse for unregistered SDKs.
- Stopped showing a warning about invalid application locations.
- Added the
nrf-connect.defaultOpenActionsetting to configure the default action when adding new applications.
- Will now use
gitfrom the toolchain package whenever available.
- Fixed an issue with SSH URLs in west manifests that would the sample browser.
- Added listing of the locations of existing SDKs under the Manage SDKs > Install SDK action.
Changes in 2023.10.49¶
- Improved CMake presets variable insertion
- Prevent build from spinning indefinitely in some cases
- Fixed visibility of minor version toolchains in the Switch Active Toolchain menu
- Stop marking builds as stale if they're built with a different installation of the same toolchain.
- Fixed overflow glitch in memory report layout
- Disable all non-essential telemetry.
Changes in 2023.11.24¶
- Now supporting and bundling nRF Util device 2.0, which speeds up device discovery.
- Updated bundled nRF Util Toolchain Manager to 0.14.1.
- Fixed toolchain version name for toolchains installed in custom locations.
- Added nRF Util version to support information
- Fixed bug where the
preLaunchTaskfield in launch.json is ignored.
- Switched to nrfjprog as the default device provider on Windows. This disables automatic device enumeration, but prevents the connected devices panel from locking up in certain environments.
- Fix a bug where the option to generate CMake Presets was unavailable.
To reduce the number of downloads and steps you need to go through to get started with the nRF Connect SDK, we have decided to move the toolchain installation part of the workflow into VS Code itself. Overall, we think this simplifies the setup and configuration process, and moves the toolchain management into one single consistent user interface.
Transitioning from using the nRF Connect for Desktop Toolchain Manager does not require any extra configuration. VS Code will find and present all toolchains you have already installed, and by default, the new toolchains will be installed next to the ones you installed through nRF Connect for Desktop.
Toolchain Management Menu¶
In order to set up a good workflow for managing and installing toolchains, we have created a new Toolchain Management Menu to replace the Welcome Window's Quick Setup section. The Toolchain Management Menu can be found in the Welcome section of the sidebar and through the
nRF Connect: Manage Toolchains command. It gathers all actions related to Toolchain management in a single menu.
From this menu, you can now:
Install a new Toolchain¶
Install the official nRF Connect Toolchain package for your version of the SDK.
All the toolchain packages you can find through the nRF Connect for Desktop Toolchain Manager will be installable from this menu.
Contrary to the nRF Connect for Desktop Toolchain Manager, this mechanism will only install the toolchain package itself, and the SDK has to be installed separately.
The toolchain installer also supports configuring alternative toolchain indexes (through the
nrf-connect.toolchainManager.indexURL configuration option), and installation location (through the
nrf-connect.toolchainManager.installDirectory configuration option).
Uninstall a Toolchain¶
Allows you to uninstall one or several toolchain packages from your machine.
Set Active Toolchain¶
This is the menu you would previously find in the Welcome Window's Quick Setup menu, but with some additional enhancements.
In addition to selecting nRF Connect SDK Toolchain packages, you can now select a specific installation of the Zephyr SDK. If the extension is able to find the required tools in your PATH environment, you can use these as well.
A recent improvement in the way Toolchain Packages are distributed allows the Toolchain Manager to reuse the same toolchain bundle with different version numbers. This previously interfered with VS Code's toolchain identification scheme, but this has now been fixed.
Toolchain specific actions¶
When an active toolchain is selected, the Toolchain Management UI also offers three actions specific to the active toolchain:
- Open Terminal Profile: Opens a new terminal in VS Code with the toolchain environment.
- Open Toolchain Directory: Opens the toolchain installation in the file explorer.
- Validate Toolchain: Runs a check of all tool versions against the requirements file of the active SDK. Any failures are reported in a terminal output window.
In previous versions of the extension, you always had to explicitly select a Toolchain version to work with to start developing. This usually happened automatically when the welcome view opened for the first time, but this step was always a bit redundant and fragile.
From this release, no configuration is necessary to get started. If you have an nRF Connect SDK toolchain package, the extension will automatically use the newest version. Otherwise, it will attempt to resolve any native toolchain installations in your
PATH, and fall back to using those tools instead.
You can still override the default toolchain by configuring the
nrf-connect.toolchain.path setting in the VS Code User Settings, or configure a specific toolchain version through the Toolchain Manager Menu.
GNUARMEMB_TOOLCHAIN_PATH from inherited environment ¶
GNUARMEMB_TOOLCHAIN_PATH environment variable was set, the toolchain environment would get corrupted in some corner cases, making builds fail when run through the extension. This has been addressed by stripping this variable from the environment passed to
In addition to installing toolchain packages, the nRF Connect For Desktop Toolchain Manager also handles installation of SDKs.
In nRF Connect for Desktop, the SDK and toolchain installation was bundled into a single action. Although this allowed for a quick and easy installation, the process to establish a West workspace around your project was unnecessarily complex, as you'd first have to install an SDK from the Toolchain Manager, then create your own from a West manifest in your own project. To improve workflows where the application defines and controls the SDK version through West, SDK management is now completely separate from toolchain management, and is handled in VS Code itself.
SDK Management Menu¶
The new SDK Mangement Menu can be accessed from the Welcome view in the sidebar or through the
nRF Connect: Manage SDKs command. The SDK Management Menu is primarily used to control the SDKs used by freestanding applications, but also offers an option to create a new West workspace, from which an SDK can be included through a West manifest.
From the new SDK Management menu, you can:
Install a new SDK for use by freestanding applications. This behaves the same as the nRF Connect for Desktop Toolchain Manager, and allows you to download and register any version of the nRF Connect SDK.
In addition to every official release of the nRF Connect SDK, you can download the
main branch to get the current development state of the SDK, or select a custom SDK repository (like Zephyr or your own fork of the SDK) by pressing the repo-button in the top right corner.
We strongly recommend building your application with an official release of the SDK, as we don't actively provide support for users on the
main branch or any alternative repositories.
Through this menu, you can uninstall one or more global SDK installations to free up storage space. Note that this action is permanent, and any changes you have made to the deleted SDK installations will be lost.
Set Active SDK¶
If you're working with freestanding applications, you can configure the active SDK installation that is used with your application.
The selection you make here will be stored in the VS Code workspace settings, which can be committed to your repository.
When an SDK is part of your VS Code workspace, or your VS Code workspace is a subdirectory of an existing SDK installation, the active SDK is always the one in your workspace, and this menu is unavailable.
Open SDK Directory¶
Opens the SDK in the operating system's file explorer.
Create West Workspace¶
An alternative to using freestanding applications along with global SDK installations, is to manage your SDK as a West Workspace.
West Workspaces allow you to set up a dedicated SDK around your application, controlled by a West manifest file. This ensures that your application always builds against the same version of the SDK, both on command line and in VS Code.
West Workspaces are structured a little differently from normal freestanding applications, as they introduce a project folder above the application repository, where the SDK and any other dependencies are instantiated. To support the transition to this alternative structure, the Create West Workspace action will initialize a West Workspace around your application directory, then move your application one level down into an
application directory, before initializing the SDK around it.
Listing unidentified SDKs¶
If a West Workspace can't be identified as a valid installation of the nRF Connect SDK or Zephyr, the extension will now present the active SDK as an "Unidentified SDK" instead of hiding it altogether.
Support for custom SDK structures¶
Previously, the extension would only look for the
zephyr directories in the root of the West Workspace, then claim that the SDK is invalid if neither can be found.
A common way of tidying up West Workspaces is to place the SDK itself under a subdirectory called
external, which would break the SDK identification mechanism in the extension.
Now, the extension will use the West modules list to determine the exact location of these directories, allowing you to structure the workspace any way you see fit.
West output moved to the Output window¶
When running west operations on your SDK, the output no longer forcibly opens in a terminal, it instead runs in a progress bar in the bottom right corner, like the build process. The raw West output can still be found in the "nRF Connect" Output channel in the bottom panel.
Create New Application¶
The workflow for creating new applications was a product of the SDK and toolchain installation process. Now that this has been split up, we were able to rework the way new projects are started into something we think is a little easier to follow and use.
New Application Menu¶
When clicking Create a new application in the Welcome view in the sidebar, VS Code will show a quickpick menu instead of the old application creation window.
From here, you can either start your application from a blank template, or pick a sample to start out from.
Create a blank application¶
When starting a new project with the nRF Connect SDK, your application will need a couple of files to be considered a valid application:
- CMakeLists.txt: Main file for the build system
- prj.conf: Kconfig settings definitions
- main.c: An entry point for your application firmware
While all samples contain these files, the samples additionally contains some sort of demonstration of APIs or behavior that you would usually end up deleting at some point in the development cycle.
Through user feedback, we have found that a lot of applications start out with the Hello World sample, as it's the closest thing to a blank application you could find.
To make this process even simpler, you can now start your project from a blank template application.
VS Code will create the smallest possible version of each of the three essential files, and set up a basic Git repository for you.
Copy a sample¶
Copying a sample was already available as an option in previous versions of the extension, but has been revamped this release.
Instead of the old sample browser, samples are now presented in a filterable list, populated from all the modules in your SDK. From this menu, you can open the local folder in the file explorer, view the documentation for your version of the SDK or view the sample on GitHub.
You can also filter the samples based on available modules and supported boards.
Once you've found the sample you would like to start your project from, VS Code will copy the sample from the SDK and set up a basic Git repository around it.
Note that you need to have a local copy of the nRF Connect SDK to copy a sample.
Another change for this workflow is that the extension will copy any external directories that are referenced from the CMakeLists.txt file, which resolves a long standing issue with samples that share common code in a directory outside the sample itself, such as the HTTP Update samples for nRF9160. The external dependencies will be copied into the application directory and any reference to them in the CMakeLists.txt file will be changed.
The old workflow for creating new applications did not differentiate between scenarios where you wanted to start a new project, and when you just wanted to try a sample from the SDK. As a result, the only way to find samples with the sample browsers was to copy them out into a separate directory, as if you were starting a new project.
Just running a sample is a distinctly different workflow, and from this release, it will be presented as such.
The new Browse samples action is available from the Welcome view in the sidebar, and lets you search through samples with the same menu as you do in the new Create a new application workflow. When browsing samples, you will no longer be forced to copy the sample to a separate directory, but can instead open it directly in the SDK.
When opening a sample in the SDK, and changes you make to the sample code will change your SDK installation, which can cause issues later if you want to change the SDK to a different version. Because of this, we highly recommend using the Create a new application workflow if you want to change the sample code.
Integration in VS Code's own panels¶
To make it even easier to get started, you can now create a new application from an empty workspace by going to the VS Code File Explorer or clicking the New File... option in the VS Code Welcome screen.
To get started with the extension, new users need to install a toolchain, get the SDK, open an application and create a build configuration. While all the tools to do so are available in the sidebar in some fashion, it's not always obvious what the next step is, and whether you have missed some important piece.
To streamline the onboarding workflow, the sidebar will now start showing you exactly what you're missing to get to the next stage, and offer present buttons for getting through the required setup.
Through this mechanism in the sidebar, the extension now guides new users through the first few steps:
- Install your first toolchain
- Get the SDK
- Create or open an application
- Create the first build configuration
- Install the nRF Command Line tools
- Initialize your West workspace
- Detect and fix broken SDK installations
Quick Start handover from nRF Connect for Desktop¶
The nRF Connect for VS Code extension pack was updated to support the new Quick Start process in nRF Connect for Desktop. Options selected in nRF Connect for Desktop will be sent to VS Code automatically, enabling a smoother flow between the two applications when getting started for the first time.
To accomodate the new Toolchain and SDK Manager Menus, the Welcome View in the sidebar has been overhauled.
To make room for the new action in the Welcome view, we have moved some buttons to the header.
The Welcome page has been removed¶
The old Welcome page would open automatically when VS Code started, and allowed you to configure your SDK and toolchain version, as well as find resources like documentation and nRF Connect for Desktop.
We found this to be a little intrusive, and with the configuration options at the top, this page ended up being more of a configuration window than a welcome screen.
The functionality you'd previously find in the Welcome screen has now been moved into the sidebar's Welcome section, where it's a little less intrusive and a little closer to the rest of the extension's functionality.
We have made two small improvements to the Applications View in this release:
Create new build configuration button¶
We have noticed that a lot of users haven't discovered the option to add more than one build configuration for each application, and would spend a lot of time editing and rebuilding the application to switch between different configurations.
To make this a little easier to do, we now show the Create new build configuration button at the end of the build configuration list for each application.
Build Configuration Tooltip: Edit button ¶
In addition to the Copy build command button, the Build Configuration Tooltip now presents the option to edit the Build Configuration.
This action is also available through the context menu for each Build Configuration.
The Input Files section of the Details view has always been a bit messy, as it has contained a collection of all files that go into a build, but that aren't source files.
This release, we have renamed this section to Config files, and its content is now both better structured, and a bit more useful.
Separate sections for Kconfig and Devicetree files ¶
While the CMakeLists.txt file is still available from the top level of the Config files section, the Kconfig and DeviceTree files have been moved into separate sections to make it easier to distinguish which files belong to each configuration system.
We have extended the list of Kconfig
.conf files to include any board and shield files.
Additionally, the Kconfig section now lets you open the active Kconfig file, and browse its inclusions as a file tree.
Zephyr recently introduced Snippets as a mechanism for defining portable build system overrides that could be applied to any application.
Any snippets you have used in your application will now show up in the Config files section as a separate subsection, and any files the snippet adds to Kconfig and Devicetree will be included in their respective subsections as well. Any configuration files pulled in by a particular snippet will also be available as entries under the snippet file.
We've made two minor improvements to the nRF Debugger in this release:
Refresh Peripheral View ¶
The peripheral view normally only reads the register state when you pause the debugger or write to any of the peripherals.
To allow you to read new values of live peripherals, we have added a refresh button at the top of the Peripherals view in the debugger.
Cleaned up memory section addition¶
We have reworked the quickpick that appears when you add a custom memory section, aligning it with the other quickpick menus.
New Build Configuration¶
The New Build Configuration screen has gotten a few upgrades to support a few common usage scenarios.
Select build optimization level ¶
We have changed the "Debug options" checkbox to a dropdown for controlling the overall optimization level. This allows you to not just switch between debugging or release optimization in the compiler, but specify exactly what sort of optimizations you would like to enable.
Contrary to other CMake build systems, the Zephyr build system uses Kconfig options to control the optimization level, which would often confuse new users. We hope this change makes the change a little smoother for new users.
Devicetree overlay selection ¶
When you create a build configuration, you have always had the option to choose both the main
.conf file and any additional Kconfig fragments from the New Build Configuration screen.
We have now added a section to select Devicetree overlay files, the same way Kconfig fragments are selected.
Board Name in board selection¶
The board selection dropdown now displays the board's name (as defined in its board definition file) in its tooltip. When filtering for board values, you will also be able to match on the board name.
To go along with the changes to the Toolchain and SDK Management, we have cleaned up the presentation of the nRF Connect status bar item.
The status bar item is also a bit more functional, and clicking the SDK or Toolchain entry will open their respective management menus.
The status bar will still present information about any persistent issues in your workspace, such as unused West manifests, ignored SDK configuration values and new updates to the nRF Command Line Tools.
We have also reduced the severity of updates to the nRF Command Line tools to an information message, instead of presenting it as a warning.
More notifications moved to status bar¶
Just like in the June release, we have moved some UI elements that used to pop up as notifications to the status bar tooltip instead.
Any problems or events that doesn't require immediate action, and that won't go away on its own, are now presented in the status bar.
This release, we have moved the release notes notification and West Workspace issues to the status bar, instead of showing them as notifications.
The Create Board workflow has been converted from a dedicated window to a series of dialogs. We eventually want to expand on this workflow with closer integration with the DeviceTree Editor, but we had some technical debt in this workflow that needed to be cleared up.
Board creation is something everyone has to do at some stage in their product development cycle, and we hope to improve this process in the upcoming releases.
C/C++ Language support¶
We have found and fixed three usability issues caused by our integration with the C/C++ extension, that provides language support and diagnostics for C/C++ files.
Refresh IntelliSense configuration when compilation ends¶
As the Zephyr build system generates some essential C files during compilation, it's important that the C language configuration is updated when the new files are added to resolve any include file issues that would show up due to missing files.
As the C/C++ extension is unable to detect this on its own, we now notify it when the compilation ends, so that it can do a rescan of open files. This resolves any lingering include issues that could occur before the application had a working build configuration.
Enforce absolute paths for indexer ¶
The nRF Connect for VS Code extension uses build system output to provide the C/C++ extension with a list of paths that should be indexed for its go-to-definition mechanism.
Some include paths would be specified as relative paths by the build system, but the C/C++ extension is not able to relate this to the build folder itself, so in some cases, it would end up indexing the entire workspace folder, which took a lot of time and resources. This would normally manifest itself as a never ending loading indicator on the C language status bar item, and generally poor performance for C/C++ language support.
We have now addressed this by converting all paths passed to the C/C++ extension to absolute paths. The C/C++ extension might take a few seconds to reset itself and purge any unneeded indexing files, but once that initial cleanup is finished, both go-to-definition and other langauge support mechanisms in C/C++ should be significantly faster.
Fixed bug in Zephyr SDK Toolchain resolution¶
In some corner cases, the nRF Connect for VS Code extension would fail to resolve raw Zephyr SDK installations, and as a result, the C/C++ extension would force open an output panel saying it couldn't find the arm-zephyr-eabi-gcc compiler.
This has now been fixed, and the nRF Connect for VS Code extension will always validate the compiler path before passing it to the C/C++ extension to prevent similar disruptive UI elements.
We have made various small improvements to other areas of the extension:
Configure the nRF Util location¶
To support any custom installations of the nRF Util tools, you can now configure the nRF Util location through the
nrf-connect.nrfutil.home configuration option in your VS Code User settings.
New board IDs¶
We have updated the board ID resolution map used to associate your connected devices with the corresponding Zephyr board IDs to include the latest boards from Nordic Semiconductor.
Improved Memory Report UI interaction¶
We have made some small improvements to the way you can interact with the Memory Report:
- Clicking an inactive section entry makes it active. Clicking an active section entry expands it.
- If you click the expand icon directly, the entry is expanded and set active at the same time.
- Clicking a symbol entry once makes the entry active. Clicking it again opens the symbol, if possible.
SonarLint extension integration¶
SonarLint is a VS Code extension for Sonar’s linter.
To make the SonarLint extension work a little better with the nRF Connect for VS Code extension, we now automatically update the SonarLint configuration to point to the active Build Configuration.
The SonarLint integration can be disabled through the
nrf-connect.thirdpartyIntegration configuration setting.
Merged West update commands¶
The extension previously presented two separate West update commands that performed West update on your workspace. These have now been merged into one, which additionally fixes an issue where the
nRF Connect: West Update command wouldn't be registered correctly.
Hid Devicetree action for Sysbuild and TFM builds¶
The Devicetree section no longer appears for Sysbuild and TFM builds, as these build types don't have a Devicetree context.