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]

[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.

Burt

[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