search

esp-rs / espflash

Serial flasher utility for Espressif SoCs and modules based on esptool.py
Apache License 2.0
478 stars 117 forks source link

connect timeout current HEAD (Heltec Wifi Lora, cp2102) #549

Closed svalouch closed 8 months ago

svalouch commented 8 months ago

Hi, I have a bunch of older boards with plain ESP32's and CP2102 USB-serial-converters. One of them, a Heltec Wifi LoRa board (the original, they seem to call it V1 now) worked with espflash version 2.1.0, but doesn't work on current HEAD:

~/espflash/espflash $ RUST_LOG=trace ../target/release/espflash board-info
[…]
[2024-01-15T20:44:53Z INFO ] Using flash stub
[2024-01-15T20:44:53Z DEBUG] Loading flash stub for chip: Esp32
[2024-01-15T20:44:53Z DEBUG] Write 12700 byte stub text
[…]
[2024-01-15T20:44:55Z DEBUG] Finish stub write
[2024-01-15T20:44:55Z DEBUG] Writing command: MemEnd { no_entry: false, entry: 1074273504 }
[2024-01-15T20:44:55Z DEBUG] Stub written!
Error: espflash::timeout

  × Error while connecting to device
  ╰─▶ Timeout while running command

I've bisected this a few times (good v2.1.0, bad 074f8bcdbcbc5890909932ec99a157837202f025 (i.e. current HEAD), and each time I end with the "first bad commit" being 775e22275b30f952457978b0c38e64942233e734. This commit is working just fine, so I'm a bit at a loss here as to what causes this behaviour or how to further debug this.

This commit, as well as tag v2.1.0 and HEAD, work perfectly fine on two other boards (a ESP32 Node-MCU-style and a custom board using an external converter, but all use a CP2102 converter chip). The result is consistent, i.e. running espflash multiple times always yields the same result for the Heltec board for all bisecting steps. For reference, esptool.py version 4.6.2 (from Arch repos) works just fine.

Host is Arch Linux on amd64, rust and cargo 1.75.0 (through rustup, stable).

Unrelated to this, I noticed in the debug output that it fires a request to crates.io on each invocation. Is that really necessary?

Edit: I just realised there's https://github.com/esp-rs/espflash/issues/546 and I can confirm that current HEAD with --no-stub works with the Heltec board. But that doesn't work for flashing, does it?

SergioGasquez commented 8 months ago

This commit is working just fine,

Just to confirm, “this commit” means the one before https://github.com/esp-rs/espflash/commit/775e22275b30f952457978b0c38e64942233e734, right?

Unrelated to this, I noticed in the debug output that it fires a request to crates.io on each invocation. Is that really necessary?

We use https://crates.io/crates/update-informer to verify if the user is using the latest release of the tool, maybe it's not “necessary” but it helps to avoid users being stuck in older version, which avoids issues.

dit: I just realised there's https://github.com/esp-rs/espflash/issues/546 and I can confirm that current HEAD with --no-stub works with the Heltec board. But that doesn't work for flashing, does it?

--no-stub also works for flashing, it might flash a bit slower, but it should work.

Perhaps we could try increasing the timeout as for some reason that devkit might be a bit slower, but this is looks more like a stub issue, it's weird that it only affects a specific esp32 devkit and not others. Could you try updating the timeout and see if the issue persists?

SergioGasquez commented 8 months ago

Hi! Do you have any updates regarding this issue?

SergioGasquez commented 8 months ago

I'll be closing this issue as I can't reproduce it, and it has been inactive, if the issue persists, feel free to reopen it!