Giters

esp-rs / espflash

Serial flasher utility for Espressif SoCs and modules based on esptool.py

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

connect timeout current HEAD (Heltec Wifi Lora, cp2102)

svalouch opened this issue · comments

commented

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 074f8bc (i.e. current HEAD), and each time I end with the "first bad commit" being 775e222.
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 #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?

commented

This commit is working just fine,

Just to confirm, “this commit” means the one before 775e222, 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 #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?

commented

Hi! Do you have any updates regarding this issue?

commented

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!