esp-rs / espflash

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

Error: espflash::connection_failed #149

Closed pengkebao closed 2 years ago

pengkebao commented 2 years ago

pengkebao@localhost esp-rust-test % espflash /dev/tty.usbserial-0001 target/riscv32imc-esp-esp
Serial port: /dev/tty.usbserial-0001 Connecting...

Unable to connect, retrying with extra delay... Unable to connect, retrying with default delay... Unable to connect, retrying with extra delay... Unable to connect, retrying with default delay... Unable to connect, retrying with extra delay... Unable to connect, retrying with default delay... Unable to connect, retrying with extra delay... Error: espflash::connection_failed

× 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

pengkebao@localhost esp-rust-test % espflash --version
espflash 1.3.0

pengkebao commented 2 years ago

pengkebao@localhost esp-rust-test % espflash /dev/tty.usbserial-0001 target/riscv32imc-esp-esp Serial port: /dev/tty.usbserial-0001 Connecting...

Unable to connect, retrying with extra delay... Unable to connect, retrying with default delay... Unable to connect, retrying with extra delay... Unable to connect, retrying with default delay... Unable to connect, retrying with extra delay... Unable to connect, retrying with default delay... Unable to connect, retrying with extra delay... Error: espflash::connection_failed

× 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

pengkebao@localhost esp-rust-test % espflash --version
espflash 1.4.0-dev

jessebraham commented 2 years ago

Sorry to hear you're having issues. Would you mind please sharing which board you are trying to flash? I have seen this issue with the ESP32 before but not with the ESP32-C3, so I'm interested where the problem lies.

LeDominik commented 2 years ago

I have exactly that problem... Running on Intel, MacOS Monterey, Rust 1.60, espflash 1.4.0, board is a FeatherS2 Neo so it's using the ESP32S2 onboard USB capabilities. The device shows up as follows

image

and leads to a /dev/cu.usbmodem01 as well as an /dev/tty.usbmodem01. However using the tty device is completely hopeless (hangs after Connecting... and CTRL+C no longer works), when using esptool.py or idf.py I always go through the cu.usbmodem01 and that works (I think idf.py did that just automagically), but espflash goes into this "Unable to connect loop" on TTY as described above, or

Error: espflash::serial_not_found

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

So that error message is a bit misleading, still hope this helps in the quest... I'll just flash with esptool.py for the time being and a shell script 😞

Update re-validated behaviour on 1.4.1

LeDominik commented 2 years ago

In case it is of help I also got a FeatherS3 recently (still unpacked) which has an ESP32S3 on it and also uses onboard USB, so if that needs testing as well, happy to do it...

Talljoe commented 2 years ago

I'm also seeing this issue with a UM FeatherS2 Neo and a Adafruit QT Py Esp32-S2, both over USB.

I'm using cargo generate --vcs git --git https://github.com/esp-rs/esp-idf-template cargo to create the project image. The below tests are without changing any code from the template.

✗  cargo espflash
Serial port: /dev/ttyACM0
Connecting...

Unable to connect, retrying with extra delay...
Unable to connect, retrying with default delay...
Unable to connect, retrying with extra delay...
Unable to connect, retrying with default delay...
Unable to connect, retrying with extra delay...
Unable to connect, retrying with default delay...
Unable to connect, retrying with extra delay...
Error: espflash::connection_failed

  × 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

I am able communicate with the chips using esptool.py:

➤  ./esptool.py --chip esp32s2 --after no_reset flash_id
esptool.py v4.0-dev
Found 1 serial ports
Serial port /dev/ttyACM0
Connecting....
Chip is ESP32-S2FNR2
Features: WiFi, Embedded Flash 4MB, Embedded PSRAM 2MB, ADC and temperature sensor calibration in BLK2 of efuse V1
Crystal is 40MHz
MAC: 84:xx:xx:xx:xx:xx
Uploading stub...
Running stub...
Stub running...
Manufacturer: 20
Device: 4016
Detected flash size: 4MB

Other chips working

UM TinyPico USB-C (Pico D4)

➤  cargo espflash
Serial port: /dev/ttyUSB0
Connecting...

    Finished dev [optimized + debuginfo] target(s) in 0.05s
Chip type:         ESP32 (revision 1)
Crystal frequency: 40MHz
Flash size:        4MB
Features:          WiFi, BT, Dual Core, 240MHz, Embedded Flash, Coding Scheme None
MAC address:       ac:xx:xx:xx:xx:xx
[00:00:01] ########################################      16/16      segment 0x1000
[00:00:00] ########################################       1/1       segment 0x8000
[00:00:23] ########################################     228/228     segment 0x10000

Flashing has completed!
➤  ./esptool.py --chip esp32 --after no_reset flash_id
esptool.py v4.0-dev
Found 1 serial ports
Serial port /dev/ttyUSB0
Connecting....
Chip is ESP32-PICO-D4 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, Embedded Flash, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: ac:xx:xx:xx:xx:xx
Uploading stub...
Running stub...
Stub running...
Manufacturer: c8
Device: 4016
Detected flash size: 4MB
Staying in bootloader.

ESP32-S3-DevKitC-1

Worked with both USB and UART/USB connectors.

➤  cargo espflash
Serial port: /dev/ttyUSB0
Connecting...

    Finished dev [optimized + debuginfo] target(s) in 0.04s
Chip type:         ESP32-S3
Crystal frequency: 40MHz
Flash size:        8MB
Features:          WiFi, BLE
MAC address:       7c:xx:xx:xx:xx:xx
[00:00:01] ########################################      13/13      segment 0x0
[00:00:00] ########################################       1/1       segment 0x8000
[00:00:25] ########################################     234/234     segment 0x10000

Flashing has completed!
➤  ./esptool.py --chip esp32s3 --after no_reset flash_id
esptool.py v4.0-dev
Found 1 serial ports
Serial port /dev/ttyUSB0
Connecting....
Chip is ESP32-S3
Features: WiFi, BLE
Crystal is 40MHz
MAC: 7c:xx:xx:xx:xx:xx
Uploading stub...
Running stub...
Stub running...
Manufacturer: c8
Device: 4017
Detected flash size: 8MB
Staying in bootloader.

Operating System Details

➤  espflash --version
espflash 1.4.1
➤  lsb_release -a
Distributor ID: Pop
Description:    Pop!_OS 21.10
Release:    21.10
Codename:   impish
➤ uname -a
Linux hostname 5.16.15-76051615-generic #202203161444~1647964027~21.10~e706226 SMP PREEMPT Tue Mar 22 17 x86_64 x86_64 x86_64 GNU/Linux
jessebraham commented 2 years ago

A contributor submitted a patch which fixed this issue for them. I would suggest trying again using the master branch. If it does not work there is obviously something else going on.

jessebraham commented 2 years ago

@LeDominik I forgot to reply to your comments earlier, sorry about that.

The /dev/.cu* ports are not enumerated by the serialport dependency, which is why they cannot be found. I'm not sure why you're having issues with the /dev/.tty* ports as they're generally recommended, and are what I have always used personally. There were previously some issues with macOS Monterrey but they have been resolved; I and others have used this application successfully on that OS so I'm not sure where exactly the problem lies. Sadly I don't have any more information right now.

I do plan on refactoring how we handle serial ports, as we make some assumptions currently which seem to be causing problems in edge cases like yours. I am not sure when this will be completed however.

alexeden commented 2 years ago

I'm experiencing the same for an Unexpected Maker FeatherS2 on MacOS. I installed 1.5.0-dev and the same issue occurs. Weirdly, when I try to run board-info with 1.5.0, it seems to kick the board into "download mode" (that's what the UM docs call it), as the names of the ports change (from /dev/tty.usbmodem14101 to /dev/tty.usbmodem01):

$ espflash board-info /dev/tty.usbmodem14101 
Serial port: /dev/tty.usbmodem14101
Connecting...

Unable to connect, retrying with extra delay...
Unable to connect, retrying with default delay...
Unable to connect, retrying with extra delay...
Unable to connect, retrying with default delay...
Unable to connect, retrying with extra delay...
Unable to connect, retrying with default delay...
Unable to connect, retrying with extra delay...
Error: espflash::connection_failed

  × 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

$ espflash board-info
Serial port: /dev/tty.usbmodem01
Connecting...

Unable to connect, retrying with extra delay...
Unable to connect, retrying with default delay...
Unable to connect, retrying with extra delay...
Unable to connect, retrying with default delay...
Unable to connect, retrying with extra delay...
Unable to connect, retrying with default delay...
Unable to connect, retrying with extra delay...
Error: espflash::connection_failed

  × 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

FWIW, I was able to upload C++ code through the Arduino IDE to the same board. It uses esptool under the hood and the upload logs indicate that it's definitely using the /dev/cu.usb* port.

mihai-dinculescu commented 2 years ago

I'm getting the same results with a FeatherS3 board from Unexpected Maker.

E:\Rust\IOT\esp32s3-test>cargo espflash
Detected 2 serial ports. Ports which match a known common dev board are highlighted.

Serial port: COM9
Connecting...

    Finished dev [optimized + debuginfo] target(s) in 0.21s
Chip type:         ESP32-S3
Crystal frequency: 40MHz
Flash size:        16MB
Features:          WiFi, BLE
MAC address:       60:55:f9:f5:40:14
Error: espflash::timeout

  × Communication error while flashing device
  ╰─▶ Timeout while running WriteReg command

E:\Rust\IOT\esp32s3-test>cargo espflash --version
cargo-espflash 1.5.1

Flashing to an Adafruit HUZZAH32 board works just fine.

jessebraham commented 2 years ago

@mihai-dinculescu that is a different error than has been reported by the other users in this issue.

There's not really anything I can do about this issue as I'm not able to reproduce it. Unless somebody tries to debug what's going on nothing is going to change any time soon.

jessebraham commented 2 years ago

Closing this due to inactivity. Anybody involved, please feel free to re-open this issue or create a new one.

KenVanHoeylandt commented 1 year ago

I just had this issue on a clean Arch install with an S3-DevKitC-1. I was using a USB-C hub on a Framework i5-1240P laptop. The solution was to connect the device to the laptop directly (with a USB-A to C adapter). Additionally, the devkit had to be put in flash mode by pressing the RESET+BOOT buttons.

reinismu commented 1 year ago

I have the same issue. I can flash using idf.py, but when I try espflush it just fails as above. I'm running m1 mac. Before I used hub, but now mac usb C to A adapter. Tho still can't get it to work.

Bought ESP32-S3-DevKitC-1, tried flashing it with espflash and it worked.