[xtask] serial-term not working on windows

[njordr]

Today I loaded the puzzle-fw into the nRF52840 dongle and tried to run the terminal console, but it failed:

PS C:\Users\gcolapinto\Workspace\rust\rust-exercises> cargo xtask serial-term
    Finished dev [unoptimized + debuginfo] target(s) in 4.14s
     Running `xtask\target\debug\xtask.exe serial-term`
Error: 
   0: The system cannot find the file specified.

Location:
   src\tasks.rs:54

Backtrace omitted. Run with RUST_BACKTRACE=1 environment variable to display it.
Run with RUST_BACKTRACE=full to include source snippets.
error: process didn't exit successfully: `xtask\target\debug\xtask.exe serial-term` (exit code: 1)

the dongle is recognized in the usb-list

PS C:\Users\gcolapinto\Workspace\rust\rust-exercises> cargo xtask usb-list
    Finished dev [unoptimized + debuginfo] target(s) in 0.16s
     Running `xtask\target\debug\xtask.exe usb-list`
Bus 001 Device 007: ID 1050:0407
Bus 001 Device 000: ID 8086:a0ed
Bus 001 Device 004: ID 8087:0026
Bus 001 Device 002: ID 04f2:b71c
Bus 001 Device 001: ID 06cb:00f9
Bus 001 Device 015: ID 1366:1051 <- J-Link on the nRF52840 Development Kit
Bus 002 Device 000: ID 8086:9a13
Bus 001 Device 006: ID 05e3:0610
Bus 001 Device 017: ID 1209:0310 <- nRF52840 Dongle (puzzle-fw)
Bus 001 Device 003: ID 046d:c52b
Bus 001 Device 005: ID 05e3:0626

And I could change the channel

PS C:\Users\gcolapinto\Workspace\rust\rust-exercises> cargo xtask change-channel 11
    Finished dev [unoptimized + debuginfo] target(s) in 0.23s
     Running `xtask\target\debug\xtask.exe change-channel 11`
requested channel change to channel 11

[miguelraz]

Thank you @njordr and apologies!

Edit: This is a previous debugging attempt that failed. Please ignore.

I had run into this on a previous debugging session but did not backtrack properly and come back to resolve this once I had solved my own issue.

I think the fix is quick but it's in our dependency, serialport - which has been starving for Windows maintainers (as stated in their README.md).

The bug isn't known about but probably related to their windows-sys migration - I've filed a MWE and will try to upstream the fix this week and a hotfix for you as well. If I had to guess, the

    let port = serialport::new(&dongle.port_name, 115200).port.open()?

that comes up in xtask/src/tasks.rs:54 when using RUST_BACKTRACE=full helps us narrow it down to the .open() call - we can probably hardcode the port_name and get on with our day, if you're in a real hurry, but I don't have any better ideas at the moment.

Good news! I found someone else who ran into the issue and found a workaround.

zephyrproject-rtos/zephyr#17266

They added a

CONFIG_USB_COMPOSITE_DEVICE=y
flag to their built and rebuilt the nRF SDK.

@jonathanpallant should have a better idea of how we can fix this.

Thanks for the report!

[jonathanpallant]

The bug is that whilst I used the IAD device class and sub-class to tell Windows to load a different driver for each interface, I didn't include the extra magic information Windows needs. The usbd-device crate has a special method to include this data in the descriptor which we should use.