failed to espflash "Failed to connect to on-device flash"

[mutantbob]

I was able to build the template app in a custom docker container

USER=root cargo generate --git https://github.com/esp-rs/esp-idf-template cargo --name blink3 --vcs none --silent -d mcu=esp32 -d std=true -d espidfver=v4.4 -d devcontainer=false
cd blink3
. /rust-build/export-esp-rust.sh 
cargo build

Since the USB port is not available to the docker container, I run espflash on the host, and it fails:

$ espflash --speed 921600 /dev/ttyACM0 target/xtensa-esp32-espidf/debug/blink3
Serial port: /dev/ttyACM0
Connecting...

Error: espflash::flash_connect

  × Failed to connect to on-device flash

I get the same error if I flash as root.

espmonitor reports

$ espmonitor  /dev/ttyACM0
ESPMonitor 0.10.0

Commands:
    CTRL+R    Reset chip
    CTRL+C    Exit

Opening /dev/ttyACM0 with speed 115200
Resetting device... done
ets Jul 29 2019 12:21:46
rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 271414342, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0030,len:1184
load:0x40078000,len:13160
load:0x40080400,len:3036
entry 0x400805e4

Before I used the arduino toolchain to install a C++ blink example, espmonitor was reporting the results of the wifi scan performed by the Adafruit-installed sketch.

What mistake am I making in the flash process?

[mutantbob]

With the help of the esp-rs matrix.org channel I was able to

$ espflash partition-table target/xtensa-esp32-espidf/debug/build/esp-idf-sys-535c49632f0f38f6/out/build/partition_table/partition-table.bin  --info
╭──────────┬──────┬─────────┬─────────┬────────────────────┬───────╮
│ Name     ┆ Type ┆ SubType ┆ Offset  ┆ Size               ┆ Flags │
╞══════════╪══════╪═════════╪═════════╪════════════════════╪═══════╡
│ nvs      ┆ data ┆ nvs     ┆ 0x9000  ┆ 0x6000 (24KiB)     ┆       │
├╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌┤
│ phy_init ┆ data ┆ phy     ┆ 0xf000  ┆ 0x1000 (4KiB)      ┆       │
├╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌┤
│ factory  ┆ app  ┆ factory ┆ 0x10000 ┆ 0x100000 (1024KiB) ┆       │
╰──────────┴──────┴─────────┴─────────┴────────────────────┴───────╯

and based on that I could use esptool.py to convert my ELF to a .bin and flash it into the app partition

bin=/tmp/esp32.bin
esptool.py --chip esp32 elf2image --flash_mode dio --flash_freq 80m --flash_size 8MB -o $bin blink1/target/xtensa-esp32-espidf/debug/blink1 &&
esptool.py --chip esp32 --port /dev/ttyACM0 --baud 921600 --before default_reset --after hard_reset write_flash -z --flash_mode dio --flash_freq 80m --flash_size 8MB 0x10000 $bin

So the microcontroller works enough to flash and run a simple blink app. There's something in espflash that is malfunctioning.

One of the folks on matrix.org hypothesized that the error message is coming from https://github.com/esp-rs/espflash/blob/aee5a8204a6efbe9997703c4e93a81601e022f24/espflash/src/flasher.rs#L231-L248 which is an fn spi_autodetect().

[mutantbob]

In case it becomes relevant, the exact hardware I am using is Adafruit ESP32 Feather V2 - 8MB Flash + 2 MB PSRAM - STEMMA QT https://www.adafruit.com/product/5400

[mutantbob]

One of the admins on the Adafruit forums tells me that the Adafruit ESP32 Feather V2 is an ESP32-PICO-MINI-02 .
https://forums.adafruit.com/viewtopic.php?f=8&t=193307&p=935491#p935472

He also provided a link to their copy of the datasheet: https://cdn-shop.adafruit.com/product-files/5400/esp32-pico-mini-02_datasheet_en.pdf

I wonder if this part has a different flashing procedure that the espflash tool does not cover.

[ryankurte]

I wonder if this part has a different flashing procedure that the espflash tool does not cover.

i have the same issue with espflash and (known working) pico-mini devices, seems likely it's an issue over there!

[Rhahi]

I have the same device with the same issue, but the recently merged PR solved this problem for me.
I installed using master (with --git --branch option) and I can flash by using --use-stub flag.

[ryankurte]

yep, this should be solved by the flash stub added in esp-rs/espflash#216, though you do need to set the --use-stub option (because i didn't want to change the default behaviour... probably could be propagated as an environmental variable too)