esp32c6: Waiting for download _after_ flashing #556
Comments
|
Minimal example // repro:
espflash shows: Logic analyzer started before step 6: The first bunch of messages shows: then there is a 8 second delay, during which espflash says "broken pipe". If I'm doing I'm on ubuntu 22.04 and I'm using espflash 2.1.0 (although it is the same with espflash from git (master)) |
|
I've also tried to use the esp idf provided bootloader, e.g. flash with for v5.1.1: same problem. EDIT:
|
|
Just tried reproducing the error and I was not able to reproduce it: |
|
Thanks for trying to reproduce this @SergioGasquez . |
|
At least in this case here, it is not the cable: I've just had another occurrence with a new chip + new cable. The fact that |
|
Just as an experiment, could you try the following? |
|
I'm just dropping in here to say I have seen what seems to be the same issue with my new esp32c6. With a fresh minimal esp-template project: I don't have time right this moment, but I wanted to chime in and say there's at least one other occurrence. It looks like I should investigate updating the firmware and I'll try the suggested experiment, but I probably won't get to those until tomorrow. |
|
I have seen this too, to reproduce my case:
|
|
Part of me was wondering if this might be a tooling configuration issue (until today I had not gotten any Rust to run on an esp32c6), and wondered if there was some weirdness in my macos setup. But it seems to not be the case. My experience above was with a Waveshare ESP32-C6-DEV-KIT-N8, which is a custom package around a ESP32-C6-WROOM-1. It still exhibits this issue. However, 20 minutes ago I received a delivery of a proper Espressif ESP32-C6-DevKitC-1, which also uses the ESP32-C6-WROOM-1. I popped it out of the box, plugged it in, ran My new (working) board has the same ESP-ROM and Build date as the one that doesn't work. For completeness, I'll mention that the |
|
I dont think this is hardware related. This looks like some timing issue to me... Without having looked at the source, I imagine there is a memory location or register which tells the first stage bootloader to stay in bootloader mode after reset and do not continue with the normal boot process (so that you can send more commands to it). Can it be that theres old data in this location/register? Just guessing here... |
|
|
does this timeout behavior persist after a cold boot? I also saw it multiple times with current HEAD, even after cold boot, i could only got the timeout cleared by manually forcing it into download mode, but not via cold boot, indicating that it didn't reset the esp correctly after a attach. |
|
Yes, the issue persists over unplug/replug until I manually put the device into download mode. |
|
Tried reproducing the issue with @MabezDev steps and using
|
|
@SergioGasquez the initial issue was about the usb/jtag connection not the uart one. There might be differences here how this is influencing it |
|
Yes sorry I should have been more clear, I've only seen it happen with USB jtag. |
|
Oh! Completely forgot that “small” detail.
UART port shows: Edit: Today, I tried again reproducing the error and Edit2: Also reproduced it on H2, so looks like a general USB Jtag Serial issue |
|
Same issue here with hello-world esp32c3 esp32c3-hal 0.15.0 Using older versions of esp-backtrace and esp-println seems to fix the issue. |
|
I've also managed to reproduce this behavior with
|
|
If I flash with Which is strange because @t-moe mentioned:
|
|
The repro steps that Mabez mentioned are not the ones I initially used when first observing the bug. If I manually put the device into bootloader mode, yes, this also occurs. But this is a different bug? (And you said it does also occur with My initial steps are these: #556 (comment) If I run these steps now with espflash 3.0.0-rc.1 I can't reproduce the bug. Also not with espflash 2.1.0. But seemingly appearing at random, suddenly these steps ^^ do trigger the bug, repeatedly. I cannot tell why and when :( I havent seen the bug appearing lately, but I'll update the issue as soon as I observe it again... |
|
I again today got the problem, running with |
|
I'll try to capture the raw usb packets, the next time I observe this. |
Looks like the behavior described in esp-rs/esp-flasher-stub#45 |
|
Please, when trying to reproduce in the future, use |
|
I'm having this problem as well with a new Waveshare ESP32-C6-DEV-KIT-N8 board. I have not been able to see "Hello, World!" at all yet. I'm using I'm selecting the "USB JTAG_serial debug unit" when flashing, as selecting the "USB Single Serial" doesn't seem to work. Flashing completes successfully, but the output is then stuck on "waiting for download" instead of printing "Hello, World!". I'm using a clean template, with the only added thing being $ cargo run --release
Finished `release` profile [optimized] target(s) in 0.21s
Running `espflash flash --monitor target/riscv32imac-esp-espidf/release/esp32-airplay-demo`
[2024-05-09T17:08:35Z INFO ] Detected 4 serial ports
[2024-05-09T17:08:35Z INFO ] Ports which match a known common dev board are highlighted
[2024-05-09T17:08:35Z INFO ] Please select a port
[2024-05-09T17:09:00Z INFO ] Serial port: '/dev/tty.usbmodem1401'
[2024-05-09T17:09:00Z INFO ] Connecting...
[2024-05-09T17:09:00Z INFO ] Using flash stub
Chip type: esp32c6 (revision v0.0)
Crystal frequency: 40 MHz
Flash size: 8MB
Features: WiFi 6, BT 5
MAC address: 40:4c:ca:43:a1:48
App/part. size: 332,752/4,128,768 bytes, 8.06%
[2024-05-09T17:09:00Z INFO ] Segment at address '0x0' has not changed, skipping write
[2024-05-09T17:09:00Z INFO ] Segment at address '0x8000' has not changed, skipping write
[2024-05-09T17:09:00Z INFO ] Segment at address '0x10000' has not changed, skipping write
[2024-05-09T17:09:01Z INFO ] Flashing has completed!
Commands:
CTRL+R Reset chip
CTRL+C Exit
ESP-ROM:esp32c6-20220919
Build:Sep 19 2022
rst:0x15 (USB_UART_HPSYS),boot:0x4 (DOWNLOAD(USB/UART0/SDIO_FEI_FEO))
Saved PC:0x408005b4
0x408005b4 - spi_flash_cache_enabled
at ??:??
waiting for downloadPressing Will continue to investigate... |
|
I have the same "waiting for download" issue while flashing on Xiao ESP32s3. After a day, I can work well with the following command. Let try and see if it works for you: (they key is --before & --after)
Hope that useful, |
|
Same issue here with ESP32H2 WROOM-03 (espflash v3.0.0) using minimal connections for USB flash (IO9 pulled down, D+, D-, 3.3V, GND). |
|
@bitmagier did you try the the different |
Just tried - there is no positive effect. (Doing the same flash on the development board works just fine) BTW: I'm wondering if my PIN configuration is really sufficient. |
|
Yeah – I believe my issue is caused by a missing hardware reset button wired to |
jessebraham
added
the
status:needs-investigation
|
I think this should be fixed once #691 is resolved |
I have a esp32c6 here that I flash using the command
espflash flash --monitor --flash-size 8mb --partition-table ./partitions.csv <elf>Sometimes I have the situation that after flashing the monitor shows:
Why is it still waiting for download? I have not pulled the strapping pin GPIO9 to low.
I have not yet found out when this happens exactly, but it seems to somehow depend on the firmware I flash...
The text was updated successfully, but these errors were encountered: