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]

Oh, it is slightly different from what I just wrote: if I change the path of nrfutil to garbage, it will act on it immediately, but the only message from nRF Connect: devices is that the device was found, because silently it is ignoring my garbage path and using the built in path for nrfutil. I think that is sub-optimal. If I set the path to an existing directory that does not have all the nrfutil tools I need (it's possible to make this type of mistake, after all), there will be no output messages to show that the command did not execute. And the system will still show the device, even when I refresh. But when I reboot VS Code the system will spin trying to find the device, if neither nrfutil-toolchain-manager is not in that directory. If I change to a directory .nrfutil that has nrfutil-toolchain-manager.exe but not nrfutil-device.exe, it will not spin after I restart VS Code, but the device will not be found.

So, I have found one case where changes won't take effect immediately. Rather than spinning due to lack of nrfutil-toolchain-manager, why not test for its presence, and alert the user that he has an erroneous choice of directory loaded into the nrfutil path configuration.

I am not trying to be a jerk about this, although it must seem that way. I know from googling that both others and I have had painful unexpected surprises when trying to detect devices with nrfutil, and I am simply trying to reverse engineer what is going on. I understand that most of these scenarios seem ridiculous, but I know that I had issues without doing anything ridiculous. I just want to feel that I have control over the situation--that I can partly debug what has caused the problems. I plan to go back to the system install version of VS Code and take another look there.

Burt

[dejans]

Hi Burt,

Burt said:

[11:47:47] nrfutil [10268]: jR { id: '50100377', capabilities: { rtt: true, erase: true, recover: true }, jlink: pn { resolve: [AsyncFunction (anonymous)], get: [Function: bound get] AsyncFunction }, device: { id: 3, serialNumber: '000050100377', traits: [Object], usb: [Object] } }

Darn, I lost my text. Summary:

1)system install prints an output message showing nrfutil-device, but single user install version shows the above message in nRF Connect:devices output.

2) The biggest bug is the user interface bug that when you change nrfutil path there is no pop up to alert the user that the plugin has to be disabled then re-enabled. Unlike the standard configuration options that take effect immediately, this one is an anomaly. Can you commit to fix this? Thanks.

1) What kind of installation (which program/tool) do you refer to when you mention system install and single user install? Is it VS Code installation?
2) Are you talking about the biggest bug in the user interface of nRF Connect for Vs Code extension?
Can you show how and where you changed nrfutil path?

Best regards,
Dejan

[Burt]

Hi Dejan,

About 1), yes, when I mention system install vs single user install, I am talking about the VS Code installation. 

About 2), this was a mistake on my part. I mistakenly thought that when I put a custom setting into the extension configuration option Nrfutil:Home that it was not picked up immediately. On the other hand, my suggestion above about testing for the existence of nrfutil-toolchain-manager.exe is probably not a bad one (even if of limited use).

But since my last post, I have found a hack that will solidly fix my problems both of not being able to Generate Support Information and of not finding a connected device: I just have to make certain that the library file nrfdl.dll is in my PATH. That seems to be the crux of my problem but given that 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. I am hoping that you and your people can debug that for me. Is it some sort of Windows Registry problem? Now let me tell you a couple of practical ways I can accomplish this hack:

1) I copy nrfdl.dll from ~/.vscode/extensions/nordic-semiconductor.nrf-connect-2024.3.25-win32-x64/platform/nrfutil/lib/nrfutil-device to ~/.vscode/extensions/nordic-semiconductor.nrf-connect-2024.3.25-win32-x64/platform/nrfutil/bin. I like this approach (albeit a hack) since it is self-contained in the extension. I could have copied the dll file to any directory in my active PATH.

2) I add any directory that has nrfdl.dll explicitly to my PATH using Windows "Edit environment variables for your account".

Again, I'd be grateful to know why any given Windows machine would misbehave and require the hack (or very often require the hack). Repeating what I said earlier, I spotted a number of posts on the web or in DevZone where people "all of a sudden" had problems with nrfutil, and their solution was to change Device Provider to nrfjprog in the extension's settings. I rejected that hack (I have been helping a friend who has some unusual issues with his custom board does not reset after flashing, and I like to have my VS Code set up as much like his as possible when I try to replicate his problems).

Burt

[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