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]

Well, this is a rarity, but a very happy one: for a long time, I was operating as a Local User on Windows, and I finally got tired of that and switched myself to an Administrative User. Then I tried the VSCode stuff above and got all those failures. Then it dawned on me to reboot (maybe I could have logged out instead.) After I finished rebooting, I restarted VS Code. BOTH problems disappeared.

But now there is another very, very annoying issue that many people have seen and yet I haven't seen any useful answer that would eliminate the need for me to open this ticket. The flash function in VS Code does not do a --erase in the west command to clean up the UICR so it always fails along with the desired board reset. Oddly enough, ONE TIME earlier tonight it actually did a --erase, but I haven't figured out how to make that come back. Crazy when the command line west command is so easy to use, but our organization requires nRF Connect for VS Code because it has some excellent features.

[error] [ Client] - Encountered error -160: Command verify_file executed for 2590 milliseconds with result -160
[ ################ ] 0.495s | Verifying image - block 5 of 5 [error] [ nRF91] - Failed while performing 'Verify' operation on target address 0x00FF8130.
-160: Data does not match in address range [0x00FF8130 - 0x00FF817F] (UICR)
Expected byte value 0xFF but read 0xFC at address 0x00FF8158.
[error] [ nRF91] - Failed while verifying device. -160: Data does not match in address range [0x00FF8130 - 0x00FF817F] (UICR)
Expected byte value 0xFF but read 0xFC at address 0x00FF8158.
[error] [ Worker] - Data does not match in address range [0x00FF8130 - 0x00FF817F] (UICR)
Expected byte value 0xFF but read 0xFC at address 0x00FF8158.
ERROR: Write verify failed.
NOTE: For additional output, try running again with logging enabled (--log).
NOTE: Any generated log error messages will be displayed.
FATAL ERROR: command exited with status 25: nrfjprog --program 'c:\ncs\v2.5.0\nrf\applications\asset_tracker_v2\build_nrf9160es\zephyr\merged.hex' --sectorerase --verify -f NRF91 --snr 50100377

* The terminal process terminated with exit code: 25.

[Burt]

Never mind, this was an eyesight/getting old issue: I didn't see that the Erase and Flash symbol differed from the Flash symbol: one having one arrow and the other having two. But in my defense, one could say there is a tradeoff between having the active GUI area for Flash being most of the line whereas the active area for Erase and Flash is limited to the symbol. If there was symmetry, it would require a tiny extra effort to click the Flash active area, but along with the hover messages, it would be more difficult for another alter Kacker to make the mistake I made.

[dejans]

Hi Burt,

Can you provide more information about your system(s) where you encountered the problem with nRF Connect for VS Code extension? Which operating system(s), version of VS Code, and version of nRF Connect for VS Code extension did you use? Did you maybe use pre-release version of the extension?

Burt said:

I have more than one Windows computer here, I am not smart enough to see how that happens automatically on the computer that does not have these problems.

In your tests, was there any Windows computer that did not have these problems?

Can you summarize the differences that you observed when using system installation vs single user installation of VS Code?

Best regards,
Dejan

[Burt]

Hi Dejan,

If you scroll up you will find an instance in which things were temporarily working and I was able to Generate Support Information, but I can also answer your questions here: the computer is running Windows 10Pro; version 22H2 with up-to-date build via Windows Update. I have 3 Windows 10 Pro machines and 1 Windows 11, all with VS Code+nrf Connect and the problem has not occurred on any of the other machines. The versions of VS Code and extension are the current ones; but I have tried the pre-release and also some older versions of the extension. The behavior did not change. Also, I thoroughly uninstalled ALL extensions and ALL VS Code instances, then reinstalled the latest standard versions: no change.

I do believe that there is a temporary caching of dll files that has caused the "now it works, now it does not" phenomenon that has been confusing to me and probably to you while you have read through this ticket. And I think the system installation vs single user installation has been a "red herring": I believe there is no difference between the two installs functioning: that I was probably thrown off the track by the chance that dll's were cached when I tried one vs the other. So maybe it's best to strike system vs single user off the list of likely root causes.

Burt

[Burt]

I did finally figure out the problem, with the help of Mark Russinovich's Process Explorer tool on the Microsoft Store. It is a bug in the extension, triggered by an uncommon situation in a modern Windows installation:

Windows environment variables like PATH are case insensitive. PATH in particular shows up on a fresh Windows installation as Path, and also shows up in most non freshly installed Windows as Path. But every so often, a "power user" might end up with it displaying as PATH rather than Path. Any program that uses the variable must be agnostic to the case that PATH or Path or PaTh (etc) displays. Your extension is not: if it sees Path as it expects, it will modify the Path (or PATH) appropriately to allow nrfutil-device to run. If it sees PATH, for example, it will not modify the PATH (or Path, etc.) properly to allow nrfutil-device.exe to run. That blocks both finding connected devices and also Generate System Information.

You can test this easily by using Edit the system environment variables, selecting the System variable Path,  Edit..., the Edit text. You can change the variable back and forth between Path and PATH very quickly.

I hope you folks will fix the extension in an upcoming release. Thanks, Dejan. By the way, it was probably years ago that my variable name case changed. There were never any problems until the recent one.

Burt

[tesc]

Hi,

Thank you for your extensive debugging and efforts for figuring this out. It is highly appreciated! I have reported the issue to our VS Code extension developers.

By the way, you mention that your Path variable probably changed years ago, and yet from what I understand you did not see any issues until recently. Does this indicate that the issue just recently appeared in the VS Code extension, or are there explanations in your end for why you did not stumble upon the issue previously?

Regards,
Terje

[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

[Burt]

Hi Bence,

I may have failed to explain the problem clearly enough, or I may have misunderstood your PATH concatenation remarks, but allow me to be verbose here, regardless. You may wish to read my final paragraph first. Let me start by copying your sentence "If that path is not configured, which is the default, then a known bundled version of that utility is used." This is the situation we wish to consider. The utility is nrfutil-device as you have stated.

Can we agree that the bundled version of nrfutil-device.exe is located at %HOMEPATH%\.vscode\extensions\nordic-semiconductor.nrf-connect-2024.3.25-win32-x64\platform\nrfutil\bin given the 2024.3.25 version of the extension?

Humor me by opening a Command Prompt and then attempting to execute that version of nrfutil-device.exe. Chances are it will fail because library nrfdl.dll is not found.

But why does the command "normally" work when run by the extension under VS Code? It works because the extension sets Path to %HOMEPATH%\.vscode\extensions\nordic-semiconductor.rnf-connect-2024.3.25-win32x64\platform\nrfutil\lib\nrfutil-device, where all the libraries are located. I know that because I used Mark Russinovich's Process Explorer to look at the nrfutil-device.exe process that you start. I looked at the environment variable Path.

The exception occurs when, prior to running VS Code, the variable Path has had its name changed to PATH. The simplest way to do that, for testing, is by the method I showed in my last post, using screenshots to help make that easy to figure out.

If you do this, you should find that Generate Support Information fails, and you are unable to locate connected devices.

Now I do see that when I am using Path (as opposed to PATH) my westEnv PATH does include the important library directory. Of course, when I use PATH (not Path), then I cannot Generate Support Information, so I do not know how offhand to see the westEnv PATH. Perhaps your point is that due to a Windows bug, if I use PATH rather than Path, then concatenation does not occur correctly and hence the westEnv PATH does not have the important library directory.?

Thanks,

Burt