Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

espflash 1.3.0+ doesn't not work under WSL with usbipd #166

Closed
Tracked by #137
Verequies opened this issue Apr 26, 2022 · 9 comments · Fixed by #179
Closed
Tracked by #137

espflash 1.3.0+ doesn't not work under WSL with usbipd #166

Verequies opened this issue Apr 26, 2022 · 9 comments · Fixed by #179
Assignees
Labels
bug Something isn't working

Comments

@Verequies
Copy link

Verequies commented Apr 26, 2022

As the title suggests, commits post 1.2.0 break compatibility with WSL and usbipd.
Connecting to the device over uart with the usual Python IDF utilities works fine.

Narrowing down the issue, it appears it started with commit 85c8eb8 .

The error shows as below:

Error: espflash::serial_not_found

  × The serial port '/dev/ttyUSB0' could not be found
  help: Make sure the correct device is connected to the host system

However the device is definitely connected and is listed under /dev/, as well as works with the Python IDF utilities.

espflash 1.4.1 works fine under a Linux host, and on Windows itself as expected.

@andywwright
Copy link
Contributor

andywwright commented May 5, 2022

same here, wsl, espflash v1.4.1

minicom can see the board perfeclty

Port /dev/ttyUSB0, 13:35:04

ESP-ROM:esp32c3-api1-20210207
Build:Feb  7 2021
rst:0xf (BROWNOUT_RST),boot:0xc (SPI_FAST_FLASH_BOOT)

ps just downgraded to 1.2.0 and it works

$ espflash board-info /dev/ttyUSB0

Serial port: /dev/ttyUSB0
Connecting...

Chip type:         ESP32-C3 (revision 3)
Crystal frequency: 40MHz
Flash size:        4MB
Features:          WiFi
MAC address:       34:b4:72:4c:46:d8

@jessebraham
Copy link
Member

I don't use Windows, so unfortunately I can't make any suggestions. It's possible this may be an issue with the serialport library, but again I have no way to verify.

@Verequies Verequies reopened this May 7, 2022
@KorvinSzanto
Copy link

I am also seeing this same behavior. screen can read from the serial port and I've had no trouble working on rp2040 boards through usbipd.

@jessebraham
Copy link
Member

@JurajSadel whenever you get a chance would you be able to take a look at this please?

@KorvinSzanto
Copy link

KorvinSzanto commented May 7, 2022

It's possible this may be an issue with the serialport library

I tested this out and I'm able to interact with /dev/ttyUSB0 using the latest version of the serialport library without issue. Also worth noting the v1.2.0 release uses the same serialport version, though I wasn't able to get it compiling to test.

I'm not sure but judging by my output the problem is that the port type is considered "unknown" rather than "usb". Adding a flag to allow SerialPortType::Unknown types wherever SerialPortType::UsbPort is explicitly allowed might fix this.

Edit:
Looks like it's resolving to Unknown here for me in WSL: https://github.com/jessebraham/serialport-rs/blob/main/src/posix/enumerate.rs#L81

@andywwright
Copy link
Contributor

andywwright commented May 8, 2022

It's possible this may be an issue with the serialport library

Kind of, but not quite. I think the true reason for this is that Ubuntu's usbip database of USB hardware identifiers does not have this kind of device (which is true for all new devices until the drivers update anyway), so the serialport crate honestly describes this port as Unknown. The question is - how should we react on that. Theoretically it should be enough to just add our port data into ~/.config/espflash/espflash.toml like so

[connection]
serial = "/dev/ttyUSB0"

[[usb_device]]
vid = "1a86"
pid = "7523"

but for whatever reason it didn't work for me. The port still could not be found despite the crate reads the conf 100% (if I make an intentional mistake there - it would yell at me). I'm not saying it's a bug, I might have missed something from the description.

However this issue will end, the error message The serial port '/dev/ttyUSB0' could not be found is very misleading, that's why it took me that much time to figure it out. The port is not could not be found, it could be found perfectly and even communicated with, but its type is unknown because it is reported as such by another crate "serialport" so please add VID and PID manually.

@jessebraham jessebraham moved this to Todo in esp-rs May 9, 2022
@jessebraham jessebraham added the bug Something isn't working label May 9, 2022
@andywwright
Copy link
Contributor

andywwright commented May 9, 2022

guys, for those who need to work with espflash on wsl NOW (me) I've created a really quick fix here https://github.com/andywswan/espflash that works like so:

Running `target/debug/espflash board-info`

Ports found by serialport crate: [SerialPortInfo { port_name: "/dev/ttyUSB0", po
rt_type: Unknown }]

Port name from espflash.toml: /dev/ttyUSB0

Adding VID and PID from conf file: SerialPortInfo { port_name: "/dev/ttyUSB0", p
ort_type: UsbPort(UsbPortInfo { vid: 6790, pid: 29987, serial_number: None, manu
facturer: None, product: None }) }

Serial port: /dev/ttyUSB0
Connecting...

Chip type:         ESP32-C3 (revision 3)
Crystal frequency: 40MHz
Flash size:        4MB
Features:          WiFi
MAC address:       34:b4:72:4c:46:d8

Installation v1.5.0-dev

git clone https://github.com/andywswan/espflash
cd ./espflash/espflash
cargo install --path .
cd ../cargo-espflash
cargo install --path .

it is not a permanent solution to the problem though as it just gets port data from espflash.toml and ignores all the previous logic completely, it's just a temporary measure until the bug is fixed.

actually I don't think it is a bag at all, I think the crate works as intended. it is a feature that silently protects you from unknown ports. the only bug here is an error message that port can not be found, that is not correct. it is found and then filtered out as "Non USB".

@JurajSadel
Copy link
Contributor

I'm sorry for the delay, can you guys test #179 if it resolves issues with wsl2, please?
@Verequies, @andywswan, @KorvinSzanto

@KorvinSzanto
Copy link

Works @JurajSadel

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

5 participants