I'm currently trying to change the flash size from 2 MB to 8 MB as I am getting the following warning:

W (269) spi_flash: Detected size(8192k) larger than the size in the binary image header(2048k). Using the size in the binary image header.

However I am unsure how to do this properly. Changing the flash size in the sdkconfig does not work either.

The crate has a very nice support for describing custom partition tables. It is just that this functionality is not exposed yet to the outside world, and currently, a partition table with a single factory app is always flashed.

We need a command-line syntax in the form of an option to read a partition table description from a file, so that one can flash their own partition tables. Ideally, the partition table file format should follow the one used in the ESP-IDF CSV format, so that we do not bring more confusion.

Regarding flashing a custom bootloader - this is less of a priority, but same here - we just need a command line option, where the user can provide their own elf or bin image of the bootloader (not sure which one would be more appropriate - perhaps elf, for symmetry with the app image).

Finally, having these two options (a custom bootloader and a custom partition table) brings the question: should it be possible to separately flash each of these (bootloader, partition table, app image), or shall we stick with the "platformio" approach, where all of these are flashed always together. Not sure what is the answer here.

When leaving the monitor open for a while (and sometimes when flashing) on Linux I see this error:

Error: 
  × Interrupted system call

I quick google tells me this "interrupted" signal can just be retried, but I'm not sure whether this needs to happen inside espflash or the underlying serial library.

The rationale behind this is simple - the less we have to support the better.

• All tools require nightly, with build-std being the only path to stable (even if it might be far away)
• With the introduction of the build-std-features flag, AFAIK build-std now has feature parity with Xargo and xbuild
• Switching means we can rely on cargo even more, for example cargo can handle this bit of code and avoid us hard-coding target names:

  espflash/espflash/src/chip/mod.rs

  Lines 106 to 113 in 4921f6e

  	/// Get the target triplet for the chip
  	pub fn target(&self) -> &'static str {
  	match self {
  	Chip::Esp8266 => "xtensa-esp8266-none-elf",
  	Chip::Esp32 => "xtensa-esp32-none-elf",
  	}
  	}
  	}

  
  (Note that that bit of code is mainly why I am opening this, as it broke when we started upstreaming std targets).

Thoughts @jessebraham @icewind1991 @ivmarkov ?

I was trying to find out why my firmware does not work, and tried to look what's in it, so after reading cargo espflash --help, I changed this:

$ cargo espflash --example ex /dev/ttyUSB0

to this:

$ cargo espflash --example ex save-image out.bin
Error: cargo_espflash::no_artifact

  × No executable artifact found
  help: If you're trying to run an example you need to specify it using the `--example` argument
        or if you're in a cargo workspace, specify the binary package with `--package`.

And after looking into the code and trying to debug that, found out I just misplaced the --example ex flag:

$ cargo espflash save-image --example ex out.bin

esptool.py reports:

Chip is ESP32D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz

I never successfully flashed my ESP32 boards with espflash /dev/ttyUSB0 image.elf, it always reports a timeout:

$ ./target/debug/espflash /dev/ttyUSB0 --board-info
Chip type: Esp32
Flash size: Flash4MB
$ ./target/debug/espflash /dev/ttyUSB0 ../esp32-hal/target/xtensa-esp32-none-elf/release/examples/serial
Error: IO error while using serial port: Operation timed out
caused by: Operation timed out

There is simply no response to begin_command(Command::FlashBegin,..) in flasher.rs:418 and it times out in connection.rs:117 in command() while waiting for a response.

I compared the behaviour with esptool.py and I think the issue is:

• main() calls Flasher::connect() which calls start_connection to reset the chip and calls enable_flash()
• main is now able to communicate with the flash
• load_elf_to_flash() calls self.start_connection() which resets the chip and does not call enable_flash()
• SPI communication with the flash is not possible (on ESP32)

I solved this for my boards both by either removing start_connection() or adding enable_flash() in load_elf_to_flash(), but I don't know if that breaks anything on esp8266 (calling enable_flash() would result in two FlashBegin Commands being issued, one in enable_flash and then one in load_elf_to_flash())

I have an ESP32 connected to my computer running macOS 11.6.2. When I connect it, /dev/tty.usbserial-0001 and /dev/cu.usbserial-0001 appear. Using esptool.py, I can connect.

$ esptool.py flash_id
esptool.py v3.3-dev
Found 8 serial ports
Serial port /dev/cu.usbserial-0001
Connecting.................
Detecting chip type... Unsupported detection protocol, switching and trying again...
Connecting.....
Detecting chip type... ESP32
Chip is ESP32-D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: [...]
Uploading stub...
Running stub...
Stub running...
Manufacturer: 54
Device: 4016
Detected flash size: 4MB
Hard resetting via RTS pin...

Using espflash version 1.2.0, I cannot.

$ espflash board-info
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

The issue is not tty vs. cu as $ esptool.py -p /dev/tty.usbserial-0001 flash_id works correctly and $espflash board-info /dev/cu.usbserial-0001 fails.

The connection failure appears to be happening in Flasher::sync(). I'm happy to provide additional information or assistance in debugging.

$ espflash /dev/cu.usbserial-0001 target/xtensa-esp32-espidf/release/led
Serial port: /dev/cu.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...

Error: espflash::timeout

  × Error while connecting to device
  ╰─▶ Timeout while running ReadReg command

Every single time I run espflash this output is sent to me. It looks like it's doing something because my previous program which is flashed stops. Looked into the issues, it is like #85 but not sure. I'm also on Mac M1 don't know if it has todo something with that. And other programs are successfully uploaded with the Arduino IDE.

Heya! I'm not very experienced with Rust, docker, or the esp8266 but I'd like to get started with a fairly simple project.

On the repo it states on the quickstart:

git clone https://github.com/esp-rs/esp32-hal
cd esp32-hal
docker run -v "$(pwd):/espflash" --device=/dev/ttyUSB0 -ti esprs/espflash --release --tool=cargo --example=blinky /dev/ttyUSB0

However, I am given the following error when running the above docker command with the --chip esp8266 option (as the chip wasn't recognized using autodetect):

error: invalid operand for instruction
  --> /root/.cargo/registry/src/github.com-1ecc6299db9ec823/xtensa-lx-rt-0.5.0/src/exception/assembly_lx6.rs:94:5
   |
94 |     llvm_asm!(
   |     ^
   |
... (followed by many similar errors)
error: instruction use requires an option to be enabled
  --> /root/.cargo/registry/src/github.com-1ecc6299db9ec823/xtensa-lx-rt-0.5.0/src/exception/assembly_lx6.rs:94:5
   |
94 |     llvm_asm!(
   |     ^
   |
... (followed by many similar errors)
error: aborting due to 173 previous errors

error: could not compile `xtensa-lx-rt`

Apparently needing 'llvm_asm' but unsure how to implement that.

Thanks!

Hi,

I'm packaging this crate for Guix System. Part of the build is also to run the test suite. As this crate is available on crates-io I just download it from there.

The only issue is when I execute the package build it fails on the tests as the test dir is not part of the crate tar.gz file. Could you please add the test directory to the crate manifest?

I have an ESP32-PICO-D4 with 4MB of flash, I believe something like (but potentially not exactly) this: https://www.aliexpress.com/item/4000473398801.html

I'm following along the xtensa-rust-quickstart, and rying to use cargo-espflash from Crates.io got me some unexpected errors:

$ cargo espflash --chip esp32 --example esp32 --target xtensa-esp32-none-elf --speed 460800 --features="xtensa-lx-rt/lx6,xtensa-lx/lx6" /dev/ttyUSB0
thread 'main' panicked at 'Unable to parse command-line arguments: unused arguments left: --target, --speed, --features=xtensa-lx-rt/lx6,xtensa-lx/lx6', /home/toby/.cargo/registry/src/github.com-1ecc6299db9ec823/cargo-espflash-0.1.1/src/main.rs:13:29
stack backtrace:
   0: rust_begin_unwind
   1: core::panicking::panic_fmt
   2: core::result::unwrap_failed
   3: cargo_espflash::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Installing from this repo directly (via cargo install --git https://github.com/esp-rs/espflash/ cargo-espflash) seems to have gone better, but I get "flash chip not supported":

cargo espflash --chip esp32 --example esp32 --speed 460800 --features="xtensa-lx-rt/lx6,xtensa-lx/lx6,esp32-hal" /dev/ttyUSB0
   Compiling xtensa-quickstart v0.1.0 (/home/toby/git/esp32/xtensa-rust-quickstart)
    Finished dev [unoptimized + debuginfo] target(s) in 0.66s
Error: flash chip not supported

Is this a limitation of the library currently, or potentially a bug? Whatever the solution, this may ultimately fix MabezDev/xtensa-rust-quickstart#30

https://github.com/esp-rs/espflash/blob/master/espflash/src/partition_table.rs#L289 checks for equality of partition subtypes and rejects the partition table when it finds two with the same subtype. It's not exactly well specified what should happen with component-specific subtypes, but I've been using two spiffs partitions in my esp-idf based project for the better part of the year without issues, so I believe those (spiffs for sure, maybe also fat) can be added as an exception.

There is some additional information we can get from chips by reading the eFuse, such as revision, MAC address, etc. It would be nice to have this functionality, however I believe this may require per-chip implementations.

I have an ESP32-S3, however the current crate version doesn't support it. Specifying the git url does work however, but it would be great to have the espflash crate updated so it works straight away.

I have tried rustup update and I tried sudo apt-get install libudev-dev

This is the JSON output:

{
  "rustc_fingerprint": 21358032055700506,
  "outputs": {
    "2797684049618456168": {
      "success": false,
      "status": "exit status: 1",
      "code": 1,
      "stdout": "",
      "stderr": "error: `-Csplit-debuginfo` is unstable on this platform\n\n"
    },
    "17598535894874457435": {
      "success": true,
      "status": "",
      "code": 0,
      "stdout": "rustc 1.58.1 (db9d1b20b 2022-01-20)\nbinary: rustc\ncommit-hash: db9d1b20bba1968c1ec1fc49616d4742c1725b4b\ncommit-date: 2022-01-20\nhost: x86_64-unknown-linux-gnu\nrelease: 1.58.1\nLLVM version: 13.0.0\n",
      "stderr": ""
    },
    "931469667778813386": {
      "success": true,
      "status": "",
      "code": 0,
      "stdout": "___\nlib___.rlib\nlib___.so\nlib___.so\nlib___.a\nlib___.so\n/home/newuser/.rustup/toolchains/stable-x86_64-unknown-linux-gnu\ndebug_assertions\nproc_macro\ntarget_arch=\"x86_64\"\ntarget_endian=\"little\"\ntarget_env=\"gnu\"\ntarget_family=\"unix\"\ntarget_feature=\"fxsr\"\ntarget_feature=\"sse\"\ntarget_feature=\"sse2\"\ntarget_os=\"linux\"\ntarget_pointer_width=\"64\"\ntarget_vendor=\"unknown\"\nunix\n",
      "stderr": ""
    }
  },
  "successes": {}
}

At present cargo-espflash and espflash use different command-line argument parsing libraries, clap and pico-args respectively. Unfortunately this has resulted in the two applications often falling out of sync with regard to features. It would be nice to consolidate as much of this as possible into the espflash crate to help maintain feature parity and minimize code duplication.

I keep trying to eradicate esptool.py from my demo crate build instructions, yet I'm constantly returning to it, because of small missing functionality in espflash. Case in point: conversion from ELF to BIN.

I do realize this conversion is available in cargo-espflash - yet - using cargo-espflash is not an option until it gets all build parameters that plain cargo has. For one, how do I pass --features x,y to cargo-espflash? Furthermore, I'm not really convinced that all works well with cargo-espflash. Trying to build my demo crate with it fails as if it can't see the build-std flags in .cargo/config.toml.

So how about folding or copying the ELF to BIN functionality in eslflash? I do realize this might require specifying the chip for which the binary will be produced, yet this is a small price to pay for the extra flexibility...?

It's great that espflash has support for existing idf applications/bootloaders/partition tables; however in recent chips there is support for the direct boot feature (read more here: https://github.com/espressif/esp32c3-direct-boot-example) which espflash currently does not support.

To fix this the following functionality should be able to be toggled on/off based on the type of application:

• Using the FirmwareImage format, direct boot won't work with this format we should instead just flash the loadable sections as is.
• flashing the partition table
• flashing the 2nd stage bootloader

Perhaps the toggle could simply be --format idf|raw defaulting to one or the other.

Currently only supports the esp32 & esp8266

We should add support for the following:

• esp32c3 #35
• esp32s2 #31

When the user does not have permissions for /dev/tty*, the error indicates connection failure. While technically correct, the error should present a suggestion to check user permissions:

espflash /dev/ttyUSB0 target/riscv32imc-esp-espidf/debug/esp32-hellow
Error: espflash::connection_failed

  × Failed to open serial port /dev/ttyUSB0
  ├─▶ Error while connecting to device
  ╰─▶ Serial port not found
  help: Ensure that the device is connected and your host recognizes the serial
        adapter

The above error was fixed by adding $USER to the dialout group:

sudo useradd -aG dialout $USER followed by reboot/logout

I am trying to run the rust-esp32-std-demo. When I try to run the cargo install espflash, the command errors out and fails to install espflash.

version of espflash I'm trying to install: v1.2.0
operating system: Linux x86_64
cargo version: cargo 1.57.0-dev
rustc version: 1.57.0-dev

Error:

error: failed to run custom build command for `libudev-sys v0.1.4`

Caused by:
  process didn't exit successfully: `/tmp/cargo-installR57Yug/release/build/libudev-sys-872bfa2eedb0d711/build-script-build` (exit status: 101)
  --- stdout
  cargo:rerun-if-env-changed=LIBUDEV_NO_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG
  cargo:rerun-if-env-changed=LIBUDEV_STATIC
  cargo:rerun-if-env-changed=LIBUDEV_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_STATIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_SYSROOT_DIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR

  --- stderr
  thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: "`\"pkg-config\" \"--libs\" \"--cflags\" \"libudev\"` did not exit successfully: exit status: 1\nerror: could not find system library 'libudev' required by the 'libudev-sys' crate\n\n--- stderr\nPackage libudev was not found in the pkg-config search path.\nPerhaps you should add the directory containing `libudev.pc'\nto the PKG_CONFIG_PATH environment variable\nNo package 'libudev' found\n"', /home/raunaksingh/.cargo/registry/src/github.com-1ecc6299db9ec823/libudev-sys-0.1.4/build.rs:38:41
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...
error: failed to compile `espflash v1.2.0`, intermediate artifacts can be found at `/tmp/cargo-installR57Yug`

Caused by:
  build failed

EDIT: see later posts for details

This issue was originally brought to my attention by (I believe) by @ivmarkov awhile back, but I'm just now getting to investigating it.

I performed 3 runs of each tool using the same project, and timed how long the process took. There is a clear discrepancy between them.

Full logs are available:

• espflash: https://gist.github.com/jessebraham/7e146941301241163e058090469d8f54
• esptool.py: https://gist.github.com/jessebraham/fb983010cde807d1da27e9aa47620d2a

It's worth nothing that esptool.py takes a .bin file which must be built from the .elf using elf2image; I'm not sure if this explains anything or not at this point in time.

If we want to be able to match the speed of esptool.py, we should implement compression.

I tried using kitty & alacritty, neither worked. I only discovered that progress bars exist when I tried using espflash on mac...

Some boards have hard buttons to manually switch to flashing mode. In that case, espmonitor often fails because it doesn't wait for human to press the button.

Please support this case.

esptool.py implements serial port auto-detection logic, which lets users omit the port name in many cases. Similar logic could be implemented in this project.

Additionally, if the serial port is provided by a USB device and we can get enough information from the OS about the serial port to map it to a USB device, we can use VID:PID pairs to detect likely candidates for the development board serial ports. This should work pretty well e.g. for ESP32-C3 built-in USB_SERIAL_JTAG.

Hey, thanks for writing this project.

Adding the lockfile to the repository would make it much easier to package it in distributions like Nixpkgs. It is also the recommended action for crates that are mainly applications for endusers.

Hi,

I have this older board and it fails to work with espflash, but works fine with esptool.py.

After a bit of debugging, I found the issue to be here:

When I change the first sleep from 100ms to 300ms, everything works fine. I suspect that something on that board is slower than usual, since the original version worked fine on an M5Stack.

Changing this delay time shouldn't have any impact on other boards, just 200ms slower writes.

Hi, I wonder why it is not doing okay in Windows? I'm using nanoESP32-C3 which should be compatible, but:

PS E:\Git\github.com\MabezDev\esp32c3-experiments> cargo espflash --speed 115200 COM4
Serial port: COM4
Connecting...

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

Which I can flash correctly with esptool

Seems CI is broken on in pre build step:

https://github.com/esp-rs/espflash/runs/4833785313?check_suite_focus=true

Utilize probe-rs to write directly to flash.

• Xtensa arch support in probe-rs
• flash algorithms for various esp chips - https://probe.rs/docs/knowledge-base/cmsis-packs/

MVP would be to try and flash the esp32c3, as probe-rs already has riscv support.

The serial device cannot be connected using espflash. However, the serial port can be opened by using espmonitor

Just bought the esp32c3, ready to burn the program for the first time

Taobao link: https://item.taobao.com/item.htm?spm=a1z09.2.0.0.7eea2e8dJZTw4u&id=652515479052&_u=u1fh48sn6cb5

The compiled project is based on https://github.com/ivmarkov/rust-esp32-std-mini.git, simple modification

Flash encryption is supported by all chips from the ESP32 and newer. We can encrypt data on the host and flash it to the target, assuming we first burn the encryption key into the target's eFuse.

For more details:
https://docs.espressif.com/projects/esp-idf/en/latest/esp32/security/flash-encryption.html

I have a binary that is around 1.2 MB. Flashing it with either the default, or with 460800 baud takes around 6 minutes.

Connecting...

WARN setting baud rate higher than 115200 can cause issues.
[00:00:07] ########################################      16/16      segment 0x1000
[00:00:00] ########################################       1/1       segment 0x8000
[00:06:01] ########################################     742/742     segment 0x30000

--speed does not affect download time, but it breaks or unbreaks monitor output, so the setting is effective.

Downloading the same binary using idf.py takes around 25 seconds in total.

Uploading stub...
Running stub...
Stub running...
Changing baud rate to 460800
Changed.
Configuring flash size...
Flash will be erased from 0x00008000 to 0x00008fff...
Flash will be erased from 0x00010000 to 0x00011fff...
Flash will be erased from 0x00001000 to 0x00007fff...
Flash will be erased from 0x00030000 to 0x00152fff...
Compressed 3072 bytes to 175...
Writing at 0x00008000... (100 %)
Wrote 3072 bytes (175 compressed) at 0x00008000 in 0.1 seconds (effective 265.0 kbit/s)...
Hash of data verified.
Compressed 8192 bytes to 31...
Writing at 0x00010000... (100 %)
Wrote 8192 bytes (31 compressed) at 0x00010000 in 0.1 seconds (effective 480.2 kbit/s)...
Hash of data verified.
Compressed 25136 bytes to 15446...
Writing at 0x00001000... (100 %)
Wrote 25136 bytes (15446 compressed) at 0x00001000 in 0.7 seconds (effective 277.0 kbit/s)...
Hash of data verified.
Compressed 1189280 bytes to 759190...
Writing at 0x00030000... (2 %)
Writing at 0x0003bd7a... (4 %)
Writing at 0x00046605... (6 %)
[...]
Writing at 0x0015059e... (100 %)
Wrote 1189280 bytes (759190 compressed) at 0x00030000 in 19.2 seconds (effective 496.2 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...
Done

According to https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/partition-tables.html it is perfectly valid to leave the offset fields blank. However, espflash rejects these csvs as malformed.

• The changes introduced with 85c8eb8 break serial port detection on macOS 12 (Monterey)

• This currently gives the following output when attempting to access a ESP32-C3-DevKitM-1:

  espflash $ cargo run --bin espflash -- board-info /dev/tty.usbserial-113110
      Finished dev [unoptimized + debuginfo] target(s) in 0.04s
       Running `target/debug/espflash board-info /dev/tty.usbserial-113110`
  Error: cargo_espflash::no_serial
  
    × No serial port specified in arguments or config
    help: Add a command line option with the serial port to use
  

• While the device is present

  espflash $ ls -l /dev/tty.usbserial-113110                                                                        (master)
  crw-rw-rw-  1 root  wheel  0x900007a 31 Jan 23:47 /dev/tty.usbserial-113110
  

• It looks like this is caused by serialport-rs currently returning USB serial devices as PciPort

  • It returns actually available devices as PciPort instead of UsbPort and so the detection from detect_usb_serial_ports returns an empty vector
  • USB serial devices are still returned from serialport::available_ports() but as PciPort.

Supporting QEMU (that is, the Espressif fork) really boils down to:

• Ability to convert an ELF to BIN (see the other issue - #78 )
• Ability to merge bootloader.bin, partitions.bin and the application BIN into a single BIN, as done here

Given that bootloader.bin and the single-factory-app version of partitions.bin that we need for QEMU are already "embedded" in espflash, that extension might be quite a minor one...

In this repo, having followed the steps in my readme.md, I'm getting these errors about the Result type in embuild source. Any help please?

error: could not compile `embuild` due to 7 previous errors
warning: build failed, waiting for other jobs to finish...
error: build failed
error[E0532]: expected tuple struct or tuple variant, found function `Ok`
   --> C:\Users\Jason\.cargo\registry\src\github.com-1ecc6299db9ec823\embuild-0.24.5\src\utils.rs:123:13
    |
123 |             Ok(result) => {
    |             ^^ not a tuple struct or tuple variant
    |
   ::: C:\Users\Jason\.cargo\registry\src\github.com-1ecc6299db9ec823\embuild-0.24.5\src\bindgen.rs:164:5
    |
164 |     cmd!("rustup", "run", "stable", "rustfmt", output_file)?;
    |     ------------------------------------------------------- in this macro invocation
    |
    = note: this error originates in the macro `cmd` (in Nightly builds, run with -Z macro-backtrace for more info)
help: consider importing one of these items instead
    |
1   | use serde::__private::Ok;
    |
1   | use std::result::Result::Ok;
    |
1   | use core::result::Result::Ok;

• Build the rust-esp32-std-hello crate as per the instructions
• Install espflash 1.0 with cargo install espflash
• Flash with espflash /dev/tty.usbserial-0204D0A0 target/xtensa-esp32-espidf/debug/rust-esp32-std-hello
• Open up a monitor: espmonitor /dev/tty.usbserial-0204D0A0

Output:

ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0048,len:12
ho 0 tail 12 room 4
load:0x3fff0054,len:4800
load:0x40078000,len:17448
load:0x4007c428,len:4840
entry 0x4007c6a0
E (94) esp_image: Segment 2 load address 0x3f40fff8, doesn't match data 0x000334e8
E (94) boot: Factory app partition is not bootable
E (96) boot: No bootable app partitions in the partition table
ets Jun  8 2016 00:22:57

rst:0x3 (SW_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
...

The builtin serial/jtag peripheral of the c3 & s3 also exposes a serial port.

With recent versions of esptool it is possible to flash via the serial port, however it is not possible to flash with espflash currently (it hangs).

To reproduce:

1. Wire up a USB cable to the serial/jtag peripheral pins.
2. lsusb should report something like this:

   Bus 000 Device 010: ID 303a:1001 303a USB JTAG/serial debug unit  Serial: 7C:DF:A1:61:E4:80
   

3. A serial port should also show up, on mac/linux it comes up under /dev/ttyX (windows untested)
4. Try and use espflash over this port

I have a project where I have 2 ota partitions and no factory partition. espflash.exe fails flashing an image with the error ╰─▶ No factory app partition was found.

Calling cargo espflash in the root of the rust-esp32-std-hello project like this:
cargo espflash --tool cargo --chip esp32 /dev/tty.usbserial-0204D0A0

Fails with:

Compiling rust-esp32-std-hello v0.4.0 (/Users/imarkov/projects/rust-esp32-std-hello)
error[E0463]: can't find crate for panic_abort

The reason is this line where you are unconditionally passing -Z build-std to Cargo.

However, rust-esp32-std-hello expects -Z build-std=std,panic_abort -Z build-std-features=panic_immediate_abort, as you can see here.

To make callouts into cargo build a bit more flexible, I would suggest that you are not passing anything explicit to cargo build (aside from the optional --release flag) and perhaps support a -- set of arguments at the end of the cargo espflash command line, where the semantics of -- would be that all of those would be passed down to cargo build as is. E.g.:
cargo espflash --tool cargo --chip esp32 /dev/tty.usbserial-0204D0A0 -- -Z build-std=std,panic_abort -Z build-std-features=panic_immediate_abort

or just
cargo espflash --tool cargo --chip esp32 /dev/tty.usbserial-0204D0A0
... which, if you remove the explicit passing of -Z build-std would pick up all cargo build-std arguments from .cargo/config.toml and work.

Basic overview, might be wrong:

1. Flash with a partition table that has ota_0 and ota_1; it presumably flashes to ota_0
2. Perform an OTA update to a firmware with changed behavior, which will write to ota_1 (the not-in-use partition) and set that as the boot partition
3. Flash with espflash again, again using a firmware that behaves differently

The result is that the ESP32 continues to behave as if step 3 never happened. I assume that it's always flashing to ota_0 and not setting it as the boot partition, so the ESP simply continues booting from ota_1.

I'm using current git version of espflash and an ESP32-C3. I accidentally made a String that slowly expands infinitely, did an OTA, then tried to fix it repeatedly using USB flashes that did not change the running code. Above is my best guess at what's going wrong.

ESP-IDF's otatool can set the boot partition, according to this doc. Alternatively erasing the otadata partition should also reset to ota_0.

Although I'm not entirely sure the description/repro is right, running otatool.py --port COM3 switch_ota_partition --slot 0 resulted in it running the firmware I was trying to run, so I'm fairly certain that the basic 'flashed firmware not being set to boot' issue is real.

Note that I might be doing something horribly wrong and I previously used the Arduino core to work with ESP32s, not the IDF or Rust.

# Name,   Type, SubType, Offset,   Size, Flags
# Note: if you have increased the bootloader size, make sure to update the offsets to avoid overlap
nvs,      data, nvs,     ,        0x6000,
otadata,  data, ota,     ,        0x2000,
phy_init, data, phy,     ,        0x1000,
ota_0,    app,  ota_0,   ,        0x1C0000,
ota_1,    app,  ota_1,   ,        0x1C0000,

I tried flashing it a few times but it always fails:

└──> % ~/.cargo/bin/espflash /dev/ttyUSB0 target/riscv32imc-esp-espidf/debug/esphome-rs
[00:00:01] ########################################      12/12      segment 0x0
[00:00:00] ########################################       1/1       segment 0x8000
Error: ────[espflash::timeout]───────────────────────────────────────────────────────────────────────

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

With esptool.py it works fine.
Using esptool.py --chip esp32c3 elf2image target/riscv32imc-esp-espidf/debug/esphome-rs && esptool.py --chip esp32c3 -p /dev/ttyUSB0 -b 460800 --before=default_reset --after=hard_reset write_flash --flash_mode dio --flash_freq 40m --flash_size 4MB 0x10000 target/riscv32imc-esp-espidf/debug/esphome-rs.bin

It's an ESP32-C3

~/.cargo/bin/espflash --board-info /dev/ttyUSB0 target/riscv32imc-esp-espidf/debug/esphome-rs
Chip type: ESP32-C3
Flash size: 4MB

I've previously used Arduino IDE to change the partition to "Huge App" (3MB No OTA, 1MB SPIFFS)
binary.gz

Subject says it all.

While having the flasher processing ELF files directly is gorgeous (and saves a ton of explanations to folks who are just starting with embedded development with the ESP), generating a .BIN file from an .ELF image does have one use case:

• OTA updates