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.

[Burt]

I followed the instructions here Use the System File Checker tool to repair missing or corrupted system files - Microsoft Support and sfc picked up some bad stuff. After running that, I hid that copy of nrfdl.dll I made and things seem to be working, even after rebooting. But I have never been able to train myself to run sfc every time one particular program gives me one or two particular problems. Questions I have, if you will look at the pop up that I showed at the very start of this ticket: Can more words be added to show where the log is? I never did find it. Secondly, can you add words like "we recommend running DISM and SFC" along with a link to the Microsoft help (or show the default options of those commands like the MS help does)?

I will have to monitor this computer to see if I have more problems. I will report back if they occur (along with whether sfc clears them up).

Burt

[Burt]

Bummer -- I let the computer sit in sleep for 1.5 hours, came back, and the two problems are back. I did an sfc /scannow and this time there are no errors reported. Also, more files than nrfdl.dll need to be "found": those others must have been cached when I had success copying nrfdl.dll to the other directory. One could add the ~/.vscode/extensions/nordic-semiconductor.nrf-connect-2024.3.25-win32-x64/platform/nrfutil/lib/nrfutil-device directory to the PATH to solve that. So we are sort of back at square 1, needing a hack to get things to work.

Burt

[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