[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](https://github.com/serialport/serialport-rs)). The bug [isn't known about but probably related to their windows-sys migration](https://github.com/serialport/serialport-rs/issues/56) - I've filed a [MWE](https://github.com/serialport/serialport-rs/issues/182) and will try to upstream the fix this week and a hotfix for you as well. If I had to guess, the ```rust 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.

https://github.com/zephyrproject-rtos/zephyr/issues/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.