Problems with nRF Connect for Visual Studio Code: nrfutil and also Generate Support Information

[Burt]

Generate Support Information fails dramatically:

I don't remember how to find the log. How many average users would have the slightest clue!!! Please help.

The other problem is one I have seen others comment on, but the usual solution makes no sense. They say to switch Device Provider from nrfutil to nrfjprog. But why would we do that? nrfutil works fine on the command line

C:\ncs\v2.5.0\nrf\applications\asset_tracker_v2> nrfutil device list
50100377
product J-Link
traits jlink, seggerUsb, usb

6&33aeebb&0&2
ports COM13
traits serialPorts

Found 2 supported device(s)

PS C:\ncs\v2.5.0\nrf\applications\asset_tracker_v2>

So why doesn't work in VS Code? The reason I find this particularly obnoxious is that the documentation states that nrfutil is the default Device Provider. So, it should just work. It is obviously in my Path, too.

Thanks.

Burt

[Burt]

Thanks, Terje for reporting the issue to the extension developers. You raise a good question about the timing of things: to be honest, I don't use VS Code frequently, and when I have used it, I have used it mainly for doing builds, without a device attached. But recently I was trying to copy the setup of my colleague while we bring up a new custom board. And I really don't know for certain when Path changed name, so that is a guess. I tried various versions of the extension and I believe the problem is not new.

Burt

[tesc]

Hi,

Feedback from the team is the issue must be something else, as the tool does handle PATH case insensitively. They suggest it may be an issue of e.g. nrfutil.home being configured wrongly, or API changes breaking old configurations.

Since a couple of issues have been discussed in this thread, for quite some length, we may have missed the point and therefore not been able to reproduce. Can you please reiterate which issue we are currently discussing, as well as clear steps for reproduction, as well as which error message, code or other faulty behavior you see when executing those steps?

Regards,
Terje

[Burt]

Hi Terje,

You won't be surprised if I was disappointed that the team was unable to replicate my findings. Let me try to answer your questions, now. Regarding configuration, one should use defaults in the configuration. That should eliminate any possibilities that the problem was one of incorrect settings. Regarding the lengthy discussion in the ticket, please understand that I was many times thrown off by what I believe is temporary caching by Windows of dll locations. So, things would appear to be fixed given something I would change, but then fail. So the important parts of the ticket are the first submission where I mention the two issues: failure to Generate Support Information and failure to show connected devices; and then the recent part that I begin with: "I did finally figure out the problem..."

The change I made to my Windows system to have the system Path environment variable display as "Path" rather than "PATH" absolutely fixed the issues once and for all. I do hope that the developers did read my "I did finally figure out the problem..." thoroughly--perhaps they missed it through all the "noise" preceding it. They should be aware that this is not a matter of whether I can run the code command from an arbitrary directory--I bet that PATH is case insensitive in that sense. Rather, the case sensitivity occurs as I described in "I did finally figure out...".

Later, to be thorough, I may confirm that this is not limited to the one laptop on which I found the issue. So expect another post from me with the results. Thanks, Terje.

Burt

[Burt]

Terje, I just verified that this happens on a second machine. Here is how you can make it happen. I will first give the regedit method, although it's not what I used prior to today.

Open regedit and go to the path Computer\HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Session Manager\Environment.

You will see the list of keys; highlight the Path key. Actually (I'm learning while doing) it won't let you rename the key from Path to PATH. So this technique is only good for viewing, not renaming. Moving on to what works (Note: I am working backwards here from a system that I changed Path to PATH for testing; I am showing changing it back from PATH to Path:

Edit the system environment variables:

/resized-image/__size/398x398/__key/communityserver-discussions-components-files/4/pastedimage1716398506936v1.png

/resized-image/__size/254x254/__key/communityserver-discussions-components-files/4/pastedimage1716398680314v2.png

/resized-image/__size/640x480/__key/communityserver-discussions-components-files/4/pastedimage1716398731085v3.png

I modified PATH to Path with that page and now I am back to 

/resized-image/__size/640x480/__key/communityserver-discussions-components-files/4/pastedimage1716398879159v4.png

You can use Regedit to double check that you changed PATH to Path or Path to PATH, but you have to be careful to click to a different regedit path and then go back to the correct one, or you won't see the change.

I hope the embedded pictures show up. I used links because I could not see the png files inline with this tool.

Bottom line: VS Code works with Path but not with PATH.

Burt

[Bence]

Dear Burt,

How PATH is handled in our extension may not be perfect, but it does account for the case-(in)-sensitiveness nature of the variable. This is not a bug in our extension, it is an ugly design flaw of Windows. The current behavior is to iterate over all environment variables that matches PATH case-insensitively and concatenate all the values, this is clearly visible in the support log that you provided. This is also the reason why we include `inherited` and `westEnv` blobs of the environment, so we can track how PATH is modified. I admit that simple concatenation is not perfect, in the next release this behavior is enhanced further not to include paths that are already listed, but there's no way to properly keep a prioritized order.

The original issue that nrfutil-device is not working is also unrelated, because it is not executed from PATH.

For device enumeration on Windows we default to `nrfjprog` that does not have hotplug capabilities. Your configuration selects `nrfutil`, so `nrfutil-device` will be used and that is executed from under the configured path of `nrf-connect.nrfutil.home`. If that path is not configured, which is the default, then a known bundled version of that utility is used. This is also preferred for most users, because there may be API changes between nrfutil and the extension.

In any case if the connected devices don't show up as you'd expect, first try to click the refresh icon to the right side of CONNECTED DEVICES view, that re-executes the enumeration.

Bence