VSCode: Feedback/issues with developing an out-of-tree driver

[crzyrndm]

I'm writing an out of tree modem cell modem driver and have some feedback that could help in making this endeavour smoother in the nRF Connect VSCode Environment

I have got to the point where the driver is compiling, is recognised by devicetree/Kconfig and can be included in the build without a problem. The majority of the issues I have remaining are around the development environment not being quite as helpful as it could be. The Zephyr module is being shared in several applications so is being added from a parent directory using the following as the first thing in CMakeLists.txt

set(REPOSITORY_ROOT_DIR ${CMAKE_CURRENT_LIST_DIR}/../../) # changes beased on project location in repository
list(APPEND ZEPHYR_EXTRA_MODULES
  ${REPOSITORY_ROOT_DIR}/zephyr_extra_modules
)

To summarise the issues (all inside VSCode and not evident in the build)

• Devicetree files continue to show "Unknown node for type" warnings on the compatible code and errors when added as a child node of a compatible peripheral
• All driver files except the source file (Devicetree, Kconfig, and CMake) are not visible in the nRF Connect extension view.
• Zephyr private includes show "cannot open source file"
• Conflict with CMake Tools extension

Devicetree error on driver node

Driver configuration files not visible in extension view

When writing a Zephyr driver, a significant part of it is the non-source configuration files. It would be really nice if I didn't have to switch views to find them. The source files are listed under "External", could something similar be done under "Input files" for these configuration files?

Whatever way you think is best, reducing reasons to switch tabs makes the VSC development experience much smoother

Includes from the private Zephyr tree

Zephyr has a number of useful utilities for various drivers in the `<zephyr>/drivers/modem` folder and my driver uses some of those files.

This fails inside VSCode but is fine for the build

zephyr_library_include_directories(
    $ENV{ZEPHYR_BASE}/drivers/modem
)

# in source
#include "modem_context.h"

This works for both

zephyr_library_include_directories(
    $ENV{ZEPHYR_BASE}/drivers
)

# in source
#include "modem/modem_context.h"

While I prefer the latter anyway, there is no reason the former should fail (as evidenced by there being no issue building the driver) and include issues are a real drag on the development experience

Extension conflicts with CMake Tools extension (and not auto-disabled in a non-zephyr folder)

The VSCode Cmake tools extension is tries to configure a normal CMake project when a folder with `CMakeLists.txt` is opened (every Zephyr project...). This doesn't work very well with Zephyr projects where west is the build system. As of right now, it would be great if the nRF extension could "claim" the folder or indicate a potential conflict (not sure if this is possible)

Along the same lines, it would be greatly appreciated if the nRF extension didn't try and run on folders that are clearly not nRF firmware projects (currently just generates spurious errors).

My ideal solution to the above would be for the nRF extension to act through CMake tools somehow (particularly for highlighting / suggestions / etc). The CMake Tools extension provides very accurate errors / highlighting / etc and also removes the current conflicting "claims" on the folder

[Øyvind]

Hello, 

Thanks for providing this feedback. I will forward it to our VS Code extension team and get back to you.

Kind regards,
Øyvind

[Øyvind]

Hello, our VS Code teams appreciates the feedback and provide the following feedback:

As they point out, the DeviceTree issue comes from the usage of ZEPHYR_EXTRA_MODULES. We're not currently including that in the search path for devicetree (and some other parts), but we should be.

The suggestion about driver configuration files is something we hadn't considered or gotten feedback about before, but it makes a lot of sense. We have an upcoming task to clean up the input file section already, as it's a bit messy. We'll make sure to take this into consideration.

The custom include paths issue is surprising, as I'd expect the C++ extension to be able to pull this out of cmake. I'll go through it and see if there's anything that's not working as intended there. It'd be interesting to know whether their build directory contains a compileCommands.json file. If they built their app with the extension, it should, but if it was build manually, it might be missing. Without it, we make a best effort guess at the compilation flags, and I'm not sure we'd be able to pick up things like this in that case.

The CMake extension was marked as a conflict pretty early on, as it had some fundamental compatiblity issues with Zephyr, as discussed in this issue in their extension repo: https://github.com/microsoft/vscode-cmake-tools/issues/915 (also see issue #1120 and #1374). They released a version that attempts to solve these issues in January though (v1.13.40), and we plan to do a re-evaluation of this conflict, as it's a pretty useful extension

Kind regards,

Øyvind

[crzyrndm]

I think the C++ extension may be having issues with any Zephyr "module", not just one added through ZEPHYR_EXTRA_MODULES or just include directories (also what I thought was a fix before didn't continue working. I have no idea how I got it to work for a little while, but it's definitely not the problem I initially thought it was)

mbedtls is a very obvious example as all of it's source files are wrapped in

#if defined(MBEDTLS_FEATURE)

and no matter what the options are enabled, the code is always highlighted as
if the option was not defined. Using ssl_cli.c as an example, opened by
clicking on the file in the "nRF Connect SDK/modules/crypto/mbedtls/library"
folder (note that the debugger has no issues stepping through these files)

files under "zephyr", "nrf", and "nrfxlib" seem to work fine, it's just
modules that are sketchy (including hal/nordic/nrfx)

[Øyvind]

Thanks for reporting. The VS code team have the following answer to this:

That's a proper bug in the extension - actually, it's two:

• On Windows, the TF-M build system appears to be writing source files with a capital letter for the drive in the source file path (C:\), but the Microsoft C++ extension converts all drive letters to lower case. Windows paths are case insensitive, but our source file lookup wasn't, so we ended up using the includes for the wrong file in TF-M on Windows.
• MBED uses #include MBEDTLS_CONFIG_FILE to link in the configuration, but cmake inserts an extra escape character before the quotes in defines, which we don't properly un-escape. This breaks this include statement, and defines like MBEDTLS_SSL_CLI_C are lost.

Both issues will be fixed in the next release, which is scheduled for the end of next week. I believe the NRFX_CHECK define issue is a different problem originating from the Microsoft C++ extension, similar to https://github.com/microsoft/vscode-cpptools/issues/3109. The go to definition call works just fine if I copy it out of the NRFX_CHECK macro to the line above, so it's being evaluated differently when passed to the macro, for some reason. I can't seem to reproduce it in a reportable manner, but I'll try to make an issue for the C++ extension all the same. It'll likely take a bit longer before it's fixed though.

[crzyrndm]

Can confirm that the issues mentioned previously now appear to be resolved

• Out of tree driver is now not showing random errors on includes
• mbedtls source is correctly highlighted

The next major issue on my list would be the idle CPU usage and general lack of responsiveness of the extension

The above was captured after ~5 minutes of no code changes (project has been open for a long time) on an i7-12700. I'm also seeing noticable lag in the on-hover tooltips (lots of "Loading..." before displaying the content)

^^ Is taken from the C/C++ log view (log level turned to Debug). This is occurring with no files currently open and never seems to complete

Speaking of inconveniences, Actions has a few edges that could be smoother

It would be good to be able to configure a few defaults for the actions buttons

• "Erase and Flash" is *much* faster than the default "Flash" action and I generally do not need to use the slower option. Would be great to be able to swap the default here
  • Also would like to use this for "Debug" as well
• "Flash" action does a build first, "Debug" doesn't. While I do get the reasoning to allow this, making it the default is frustrating. An easy way to change this default would be greatly appreciated
  • There is the "preLaunch" launch config option, but a) not sure how to refer to the build action and b) it hardcodes the build folder and again not sure how to get around that

[Øyvind]

Hi! Thanks for confirming that the issue is resolved. I have forwarded the feature request to improve "Actions" buttons.

As the CPU idle time is not related to the out-of-tree driver. Could you please open a new ticket with your issue to keep this ticket on topic?

Thanks!

Kind regards,
Øyvind

[crzyrndm]

New ticket here devzone.nordicsemi.com/.../high-idle-cpu-usage-with-vscode-and-more-streamline-vscode-actions