Error: espflash::connection_failed

[markszente]

Hello,

I'm trying to use espflash on windows, installed via cargo. I tried with different boards and cables, but keep getting the above error. Windows does detect the boards when I connect them, and I can use PuTTY to read their outputs. Both boards and cables work with my Mac.

Any idea what I could do?

[SergioGasquez]

Hi!

Could you paste the full error code? I assume you are using latest released version, it might be also good to try installing main: cargo install espflash --git https://github.com/esp-rs/espflash. Which boards are you trying to use?

Both boards and cables work with my Mac.

Just to confirm, they work using espflash?

[markszente]

Thanks for the reply! I was using 2.1.0. Trying with main:

C:\Users\Mark>espflash -V
espflash 3.0.0-dev

C:\Users\Mark>espflash board-info
[2023-12-20T17:38:32Z INFO ] Serial port: 'COM5'
[2023-12-20T17:38:32Z INFO ] Connecting...
Error: espflash::connection_failed

  x Error while connecting to device
  `-> Failed to connect to the device
  help: Ensure that the device is connected and the reset and boot pins are not being held down

They're LoRa32 V2.1_1.6 board, and yes, both can be flashed on Mac using the latest stable espflash.

I tried playing around with the --baud and --chip arguments, but getting the same result.

[SergioGasquez]

Are you using WSL or WSL2? Have you tried holding down reset and boot pins as the help says?

[markszente]

No, I'm running the tool directly on Windows. But I have WSL2 installed if that's what you're asking. Doesn't it say ensure they're not being held down? :) But yes, I tried both ways.

Also, esptool.py seems to work fine, although I'm not familiar with it:

C:\Users\Mark>esptool.py --port COM5 chip_id
esptool.py v4.7.0
Serial port COM5
Connecting....
Detecting chip type... Unsupported detection protocol, switching and trying again...
Connecting.....
Detecting chip type... ESP32
Chip is ESP32-PICO-D4 (revision v1.1)
Features: WiFi, BT, Dual Core, 240MHz, Embedded Flash, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 64:b7:08:bb:38:dc
Uploading stub...
Running stub...
Stub running...
Warning: ESP32 has no Chip ID. Reading MAC instead.
MAC: 64:b7:08:bb:38:dc
Hard resetting via RTS pin...

[markszente]

So I've been debugging a little bit. The timeout originates from here:

espflash/espflash/src/connection/mod.rs

Line 268 in 77fd5b4

self.decoder.decode(&mut self.serial, &mut tmp)?;

When I remove the ? operator and do something like this:

let text = String::from_utf8_lossy(&tmp);
println!("text: {:#?}", text);

The following gets printed:

\u{1b}[0;32mI (31) boot: ESP-IDF v5.1-beta1-378-gea5e0ff298-dirt 2nd stage bootloader\u{1b}[0m\r\n\u{1b}[0;32mI (31) boot: compile time Jun  7 2023 07:48:23\u{1b}[0m\r\n\u{1b}[0;32mI (33) boot: 
Multicore bootloader\u{1b}[0m\r\n\u{1b}[0;32mI (37) boot: chip revision: v1.1\u{1b}[0m\r\n\u{1b}[0;32mI (41) boot.esp32: SPI Speed      : 40MHz\u{1b}[0m\r\n\u{1b}[0;32mI (46) boot.esp32: SPI Mode      
 : DIO\u{1b}[0m\r\n\u{1b}[0;32mI (50) boot.esp32: SPI Flash Size : 4MB\u{1b}[0m\r\n\u{1b}[0;32mI (55) boot: Enabling RNG early entropy source...\u{1b}[0m\r\n\u{1b}[0;32mI (60) boot: Partition Table:\u{1b}[0m\r\n\u{1b}[0;32mI (64) boot: ## Label            Usage          Type ST Offset   Length\u{1b}[0m\r\n\u{1b}[0;32mI (71) boot:  0 nvs              WiFi data        01 02 00009000 00006000\u{1b}[0m\r\n\u{1b}[0;32mI (79) boot:  1 phy_init         RF data          01 01 0000f000 00001000\u{1b}[0m\r\n\u{1b}[0;32mI (86) boot:  2 factory          factory app      00 00 00010000 003f0000\u{1b}[0m\r\n\u{1b}[0;32mI (94) boot: End of partition table\u{1b}[0m\r\n\u{1b}[0;32mI (98) esp_image: segment 0: paddr=00010020 vaddr=3f400020 size=0c1b4h ( 49588) map\u{1b}[0m\r\n\u{1b}[0;32mI (124) esp_image: segment 1: paddr=0001c1dc vaddr=3ffb0000 size=0000ch (    12) load\u{1b}[0m\r\n\u{1b}[0;32mI (125) esp_image: segment 2: paddr=0001c1f0 vaddr=40080000 size=01848h (  6216) load\u{1b}[0m\r\n\u{1b}[0;32mI (133) esp_image: segment 3: paddr=0001da40 vaddr=00000000 size=025d8h (  9688) \u{1b}[0m\r\n\u{1b}[0;32mI (142) esp_image: segment 4: paddr=00020020 vaddr=400d0020 size=44970h (280944) map\u{1b}[0m\r\n\u{1b}[0;32mI (249) boot: Loaded app from partition at offset 0x10000\u{1b}[0m\r\n\u{1b}[0;32mI (249) boot: Disabling RNG early entropy source...\u{1b}[0m\r\n\u{1b}[32mINFO - Logger is setup\u{1b}[0m\nHello world!\n \n \n!! A panic occured in 'src/main.rs', at line 85, column 20\n \nPanicInfo {\n    payload: Any { .. },\n    message: Some(\n        called `Result::unwrap()` on an `Err` value: BusWriteError,\n    ),\n    location: Location {\n        file: \"src/main.rs\",\n        line: 85,\n        col: 20,\n    },\n    can_unwind: true,\n    force_no_backtrace: false,\n}\n \nBacktrace:\n \n0x4010c973\n0x400d3ea0\n0x400e2269\n0x400e3362\n0x40103151\n0x40102c35\n0x401030bc\n0x401031a9\n0x400d8504\n0x400dade2\n

I guess it gets "cut" or something due to disconnect. I'm a bit tired so I don1t fully understand how the code works, and I realize it would be better suited for an issue at this point, but hey, I hope it helps.

[SergioGasquez]

Mmm that is weird, I just tried to flash on Windows, using espflash 3.0.0-dev and had no issues:

❯ cargo r
    Finished dev [unoptimized + debuginfo] target(s) in 1.10s
     Running `espflash flash --monitor target\xtensa-esp32-none-elf\debug\esp32`
[2023-12-22T10:39:59Z INFO ] Detected 3 serial ports
[2023-12-22T10:39:59Z INFO ] Ports which match a known common dev board are highlighted
[2023-12-22T10:39:59Z INFO ] Please select a port
[2023-12-22T10:40:00Z INFO ] Serial port: 'COM5'
[2023-12-22T10:40:00Z INFO ] Connecting...
[2023-12-22T10:40:01Z INFO ] Using flash stub
Chip type:         esp32 (revision v3.0)
Crystal frequency: 40MHz
Flash size:        4MB
Features:          WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
MAC address:       8c:4b:14:15:a8:a4
App/part. size:    180,016/4,128,768 bytes, 4.36%
[00:00:01] [========================================]      17/17      0x1000
[00:00:00] [========================================]       1/1       0x8000
[00:00:07] [========================================]      69/69      0x10000
[2023-12-22T10:40:13Z INFO ] Flashing has completed!
...
I (186) boot: Disabling RNG early entropy source...
Hello world!
Loop...
Loop...

I've also asked other colleagues which also use espflash on Windows, but most of them are on vacations at the moment. Also, could you try using a different USB port?

[SergioGasquez]

Might be related with #534. Are you running Windows 10?

[markszente]

Yes, using Windows 10.

[SergioGasquez]

Can you check if the strapping pins are being used https://docs.espressif.com/projects/esptool/en/latest/esp32/advanced-topics/boot-mode-selection.html#select-bootloader-mode?

[markszente]

I don't think those pins are exposed on my board. Grabbed another that has a boot button and tried with it, but to no avail. The boards work with another Windows-based PC, so it's weird.

[SergioGasquez]

The boards work with another Windows-based PC, so it's weird.

Just to confirm, using espflash, right?

[markszente]

Yes. That's why I opened it as a discussion and not a bug report.

[SergioGasquez]

Then I guess it comes down to hardware thing or drivers thing. Can you try with other ports of the computer? Have you played with zadig in the past or modified the drivers in any way?

[markszente]

Getting the same results with all ports, unfortunately. Any specific debugging steps I should take? I mean, wouldn't hardware issues mean esptool.py and basic serial communication with the boards shouldn't work either?

Have you played with zadig in the past or modified the drivers in any way?

Nope, nothing of that sort.

[markszente]

I don't know if it was the cause, or just a curious case of post hoc ergo propter hoc, but I had been dealing with an acute lack of free space on my system drive. After freeing up multiple gigabytes of space, the issue is gone.