nrfutil device list command fails

[Ronald Hoogenboom]

I just freshly (Nov 25, 2024) installed the nrfutil 'core' exe and the nrfutil device command.

I try to list my nrf devices (a nrf52840 dongle is connected and another nrf52840 through jlink), but the command fails:

$ nrfutil device list
thread '<unnamed>' panicked at src\serialport\module\src\windows.rs:118:55:
called `Option::unwrap()` on a `None` value
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread '<unnamed>' panicked at core\src\panicking.rs:221:5:
panic in a function that cannot unwind
stack backtrace:
0: 0x7ffcc9b646a1 - nrfdl_plugin_identifier
1: 0x7ffcc9b760d9 - nrfdl_plugin_identifier
2: 0x7ffcc9b62de7 - nrfdl_plugin_identifier
3: 0x7ffcc9b65ea9 - nrfdl_plugin_identifier
4: 0x7ffcc9b65a2c - nrfdl_plugin_identifier
5: 0x7ffcc9b66722 - nrfdl_plugin_identifier
6: 0x7ffcc9b665bf - nrfdl_plugin_identifier
7: 0x7ffcc9b64def - nrfdl_plugin_identifier
8: 0x7ffcc9b66206 - nrfdl_plugin_identifier
9: 0x7ffcc9b84e6d - nrfdl_plugin_identifier
10: 0x7ffcc9b84f13 - nrfdl_plugin_identifier
11: 0x7ffcc9b84fab - nrfdl_plugin_identifier
12: 0x7ffcc9a6dcab - nrfdl_plugin_enumerate
13: 0x7ffcf43b1060 - <unknown>
14: 0x7ffcf43b4d38 - is_exception_typeof
15: 0x7ffd491149c6 - RtlCaptureContext2
16: 0x7ffcc9a6d946 - nrfdl_plugin_enumerate
17: 0x7ffd0f02933a - <unknown>
18: 0x7ffd0f0268bd - <unknown>
19: 0x7ffd0f023e86 - <unknown>
20: 0x7ffd0f023b6f - <unknown>
21: 0x7ffd0f004553 - <unknown>
22: 0x7ffd0f024822 - <unknown>
23: 0x7ffd0f027e03 - <unknown>
24: 0x7ffd0f004e64 - <unknown>
25: 0x7ffd0f003918 - <unknown>
26: 0x7ffd1da229a9 - Concurrency::details::_Schedule_chore
27: 0x7ffd490d287a - RtlHashUnicodeString
28: 0x7ffd490a5e46 - RtlClearThreadWorkOnBehalfTicket
29: 0x7ffd46ee257d - BaseThreadInitThunk
30: 0x7ffd490caf08 - RtlUserThreadStart
thread caused non-unwinding panic. aborting.
Error: Subprocess C:\Users\ronaldh\.nrfutil\bin\nrfutil-device.exe failed with unexpected exit code Some(-1073740791)

Setting the RUST_BACKTRACE env-var produces the extra:

Stack backtrace:
0: git_odb_object_data
1: git_odb_object_data
2: git_midx_writer_new
3: <unknown>
4: <unknown>
5: <unknown>
6: <unknown>
7: git_odb_object_data
8: <unknown>
9: git_midx_writer_new
10: BaseThreadInitThunk
11: RtlUserThreadStart

Unplugging either or both connected nrf devices from USB doesn't change the behavior.

What gives?

NOTE: programming the nrf52840 dongle using the programmer tool in "nrf connect desktop" is just fine.

[dejans]

Hi,

Can you provide more information about your environment?

I just freshly (Nov 25, 2024) installed the nrfutil 'core' exe and the nrfutil device command.

Which "nrfutil" and "nrfutil device" versions do you use?

Where did you install nrfutil from?

$ nrfutil device list
thread '<unnamed>' panicked at src\serialport\module\src\windows.rs:118:55:
called `Option::unwrap()` on a `None` value
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread '<unnamed>' panicked at core\src\panicking.rs:221:5:
panic in a function that cannot unwind

Is this recent problem? Did you have this issue before?

Best regards,
Dejan

[Ronald Hoogenboom]

As I said I just installed it today from the internet, so yes it is a recent problem and no I didn't have this issue before.

$ nrfutil.exe --version
nrfutil 7.12.0 (39003c9 2024-06-10)
commit-hash: 39003c9d0e5d946af0f417cfadf4ac55a6d03c19
commit-date: 2024-06-10
host: x86_64-pc-windows-msvc
build-timestamp: 2024-06-10T15:56:55.227746900Z
classification: nrf-external

$ nrfutil.exe device --version
nrfutil-device 2.7.6 (040a257 2024-11-15)
commit-hash: 040a25785d0b79da111e042ef002f04cf8547e46
commit-date: 2024-11-15
host: x86_64-pc-windows-msvc
build-timestamp: 2024-11-15T10:11:07.009117500Z
classification: nrf-external

Detected SEGGER J-Link version: JLink_V7.94i

[dejans]

Hi,

Can you try to update your "nrfutil device" to the newest version and retake logs if problem persists?

Best regards,
Dejan

[Ronald Hoogenboom]

The 2.7.16 version of nrfutil-device solves the problem! Thanks.

Here is the --loglevel trace: 2251.nrfutil-device.log

[dejans]

Hi,

Ronald Hoogenboom said:

The 2.7.16 version of nrfutil-device solves the problem! Thanks.

This is great to hear. Thank you for this update.

Best regards,
Dejan

[Ronald Hoogenboom]

Just for curiousity, what was changed?
Not much, there is still:

[2025-02-18T12:40:49.073Z] [27268] DEBUG - [serialport] No com name found for \\?\USB#VID_04E8&PID_6860&Modem#7&225ecf2a&0&0001#{86e0d1e0-8089-11d0-9ce4-08003e301f73}

While the com name is definitely there in the [Device Parameters].PortName.

Well, as long as all USB serial drivers keep putting the com name in the friendlyName property, you will be safe.

[Ronald Hoogenboom]

I cooked up some demonstration code that uses the 'Device Parameters'.PortName to find the com name.
usbserial.cpp

compile with g++ -o usbserial -DUNICODE -DNOMINMAX usbserial.cpp -lsetupapi

Example run:

$ ./usbserial.exe
Device Path: \\?\usb#vid_04e8&pid_6860&modem#7&225ecf2a&0&0001#{86e0d1e0-8089-11d0-9ce4-08003e301f73}, Port Name: COM3
Device Path: \\?\ftdibus#vid_0403+pid_6001+ft1m8em3a#0000#{86e0d1e0-8089-11d0-9ce4-08003e301f73}, Port Name: COM6
Device Path: \\?\ftdibus#vid_0403+pid_6001+ftynzocqa#0000#{86e0d1e0-8089-11d0-9ce4-08003e301f73}, Port Name: COM11

nrfutil device list output in the same situation:

$ nrfutil device list
852000411
product J-Link
traits jlink, seggerUsb, usb

FT1M8EM3
product US232R
ports COM6
traits serialPorts, usb

FTYNZOCQ
product UC232R
ports COM11
traits serialPorts, usb

Found 3 supported device(s)

[dejans]

Hi,

Ronald Hoogenboom said:

Not much, there is still:

[2025-02-18T12:40:49.073Z] [27268] DEBUG - [serialport] No com name found for \\?\USB#VID_04E8&PID_6860&Modem#7&225ecf2a&0&0001#{86e0d1e0-8089-11d0-9ce4-08003e301f73}

Can you provide more information about *No com name found*? What was your test setup in this case?

Ronald Hoogenboom said:

I cooked up some demonstration code that uses the 'Device Parameters'.PortName to find the com name.
usbserial.cpp

Can you elaborate on what this sample (demo code) demonstrates?

Best regards,
Dejan

[Ronald Hoogenboom]

My setup included the samsung phone on the USB bus. The line was copied from the 2251.nrfutil-device.log I attached earlier. The "No com name found" line is for the samsung phone, which has com3.

The sample demo code shows how to get to the correct com name for devices like the samsung phone that don't put the com name in the FriendlyName property using the windows API. Using this method, the nrf-device.exe can be made more 'reliable', although it might be questionable if any serial devices that have drivers that don't put the com name in the FriendlyName will ever be "supported" by nrfutil.

Indeed if you ask CoPilot how to get the com port name for usb attached serial devices in windows, he suggests to parse the FriendlyName property too at first, so I guess it is quite common practice to do that. Obviously, common practice doesn't always represent best practice.

For now, just ignoring all serial devices that don't have a com name somewhere in the FriendlyName property instead of crashing if such a device is encountered is an acceptable improvement.

[dejans]

Hi,

Thank you for additional information and your feedback.

Ronald Hoogenboom said:

For now, just ignoring all serial devices that don't have a com name somewhere in the FriendlyName property instead of crashing if such a device is encountered is an acceptable improvement.

Do you have any further questions? Can we consider your initial issue resolved?

Best regards,
Dejan

[Ronald Hoogenboom]

yes, the initial issue is resolved. Just my suggestion for further improvement remains and it is up to you if you want to take that suggestion. I think I have provided enough information so that it is clear what that suggestion is exactly.