failed to espflash "Failed to connect to on-device flash"
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?
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().
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
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.
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!
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.
yep, this should be solved by the flash stub added in https://github.com/esp-rs/espflash/pull/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)