Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to flash ESP32S3 prototype board #323

Closed
reinismu opened this issue Dec 17, 2022 · 11 comments · Fixed by #487
Closed

Unable to flash ESP32S3 prototype board #323

reinismu opened this issue Dec 17, 2022 · 11 comments · Fixed by #487
Labels
bug Something isn't working
Milestone

Comments

@reinismu
Copy link

reinismu commented Dec 17, 2022

Recently I got my hands on prototype board that uses ESP32S3 chip. It requires entering flash mode pressing buttons.

I can't manage to flash it using espflash

~/projects/hub ❯ espflash flash -p /dev/tty.usbserial-110 -b 115200 target/xtensa-esp32s3-espidf/release/hub                                                                        х INT 18:47:11
[2022-12-17T02:47:35Z INFO ] Serial port: '/dev/tty.usbserial-110'
[2022-12-17T02:47:35Z INFO ] Connecting...
[2022-12-17T02:47:36Z INFO ] Unable to connect, retrying with extra delay...
[2022-12-17T02:47:37Z INFO ] Unable to connect, retrying with default delay...
[2022-12-17T02:47:38Z INFO ] Unable to connect, retrying with extra delay...
[2022-12-17T02:47:39Z INFO ] Unable to connect, retrying with default delay...
[2022-12-17T02:47:39Z INFO ] Unable to connect, retrying with extra delay...
[2022-12-17T02:47:40Z INFO ] Unable to connect, retrying with default delay...
[2022-12-17T02:47:41Z INFO ] 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

Tho it works perfectly fine using idf.py

~/esp/hello_world ❯ idf.py -p /dev/tty.usbserial-110 flash -b 115200                                                                                                                         х INT 18:47:46
Executing action: flash
Running ninja in directory /Users/user/esp/hello_world/build
Executing "ninja flash"...
[1/5] cd /Users/user/esp/hello_world/build/esp-idf/esptool_py && /Users/user/.espressif/python_env...o_world/build/partition_table/partition-table.bin /Users/user/esp/hello_world/build/hello_world.bin
hello_world.bin binary size 0x2eaf0 bytes. Smallest app partition is 0x100000 bytes. 0xd1510 bytes (82%) free.
[2/5] Performing build step for 'bootloader'
[1/1] cd /Users/user/esp/hello_world/build/bootloader/esp-idf/esptool_py && /Users/user/.espressif/python_env/idf4.4_py3.10_env/bin/python /Users/user/esp/esp-idf/components/partition_table/check_sizes.py --offset 0x8000 bootloader 0x0 /Users/user/esp/hello_world/build/bootloader/bootloader.bin
Bootloader binary size 0x5180 bytes. 0x2e80 bytes (36%) free.
[2/3] cd /Users/user/esp/esp-idf/components/esptool_py && /Users/user/.espressif/tools/cmake/3.23....user/esp/hello_world/build" -P /Users/user/esp/esp-idf/components/esptool_py/run_serial_tool.cmake
esptool.py esp32s3 -p /dev/tty.usbserial-110 -b 115200 --before=default_reset --after=hard_reset write_flash --flash_mode dio --flash_freq 80m --flash_size 2MB 0x0 bootloader/bootloader.bin 0x10000 hello_world.bin 0x8000 partition_table/partition-table.bin
esptool.py v3.3.2
Serial port /dev/tty.usbserial-110
Connecting....
Chip is ESP32-S3
Features: WiFi, BLE
Crystal is 40MHz
MAC: 7c:df:a1:eb:d0:64
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Flash will be erased from 0x00000000 to 0x00005fff...
Flash will be erased from 0x00010000 to 0x0003efff...
Flash will be erased from 0x00008000 to 0x00008fff...
Compressed 20864 bytes to 13011...
Writing at 0x00000000... (100 %)
Wrote 20864 bytes (13011 compressed) at 0x00000000 in 1.5 seconds (effective 111.9 kbit/s)...
Hash of data verified.
Compressed 191216 bytes to 101048...
Writing at 0x00010000... (14 %)
Writing at 0x0001b615... (28 %)
Writing at 0x00020e4d... (42 %)
Writing at 0x00026d7e... (57 %)
Writing at 0x0002ee12... (71 %)
Writing at 0x000376b2... (85 %)
Writing at 0x0003d5c4... (100 %)
Wrote 191216 bytes (101048 compressed) at 0x00010000 in 9.4 seconds (effective 162.2 kbit/s)...
Hash of data verified.
Compressed 3072 bytes to 103...
Writing at 0x00008000... (100 %)
Wrote 3072 bytes (103 compressed) at 0x00008000 in 0.1 seconds (effective 378.6 kbit/s)...
Hash of data verified.

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

Has anyone else stumbled on this?
Thanks!

p.s. It works fine when I try to flash dev board

@SergioGasquez
Copy link
Member

Hi!

@reinismu
Copy link
Author

reinismu commented Jan 3, 2023

Hi!

Which rc version of espflash 2.0 are you using?

I used both 1.7 and 2.0. Then I cloned master and tried to modify and maybe figure it out on my own. (Didn't manage to)

Do you have anything connected on boot mode selection pins?

I'm pretty new to hardware, but I assume yes. For me to flash the board I have to hold down 1 button while pressing and releasing the other. Then it enters boot mode (It tells me so through UART).

By "dev board", do you mean ESP32-S3-DevKitC-1?

Yes

If I use idf.py flashing it works. Maybe because it has a wait logic coded inside differently?

@Andrew-Collins
Copy link

Andrew-Collins commented Jan 9, 2023

I am also seeing this on the ESP32-S3-DevKitM-1 (using the idf-rust docker image, all_1.66.0.0), so I took a look at esptool and saw that they have a unix specific reset:
https://github.com/espressif/esptool/blob/f37f38433786f73d8a8274b146859ac9955ac1e7/esptool/reset.py#L74

So I modified espflash and was able to connect without having to put the board in boot mode manually.

diff --git a/espflash/src/connection.rs b/espflash/src/connection.rs
index e653885..aa73f73 100644
--- a/espflash/src/connection.rs
+++ b/espflash/src/connection.rs
@@ -136,6 +136,13 @@ impl Connection {
             self.serial.write_data_terminal_ready(false)?;
             self.serial.write_request_to_send(false)?;
         } else {
+            self.serial.write_data_terminal_ready(false)?;
+            self.serial.write_request_to_send(false)?;
+
+            self.serial.write_data_terminal_ready(true)?;
+            self.serial.write_request_to_send(true)?;
+
             self.serial.write_data_terminal_ready(false)?;
             self.serial.write_request_to_send(true)?;
 
@@ -148,6 +155,7 @@ impl Connection {
             sleep(Duration::from_millis(millis));
 
             self.serial.write_data_terminal_ready(false)?;
+            self.serial.write_request_to_send(false)?;
         }
 
         Ok(())

Post flash/command reset still doesn't work; so requires a manual reset, either using the button or Ctr + R if using monitor.

@reinismu
Copy link
Author

I just tried flashing with version espflash 1.6.0, but on linux computer as well and it worked

So issue must be in my M1 Macbook air or Espflash version. Will test it

@jessebraham jessebraham added the bug Something isn't working label Jan 10, 2023
@senior-cpp-developer
Copy link

Observing the same behavior with Lilygo T-QT Pro (ESP32-S3) on Ubuntu 22.10. Patch provided by @Andrew-Collins worked on 2.0.0-rc.3 (Thank you very much!)

@jessebraham jessebraham added this to the v2 milestone Jan 16, 2023
@jessebraham jessebraham self-assigned this Jan 16, 2023
@liebman
Copy link

liebman commented Jan 16, 2023

I see this with write-bin on espflash 2.0.0-rc.3 where cargo espflash flash has no problem connecting with the serial port. Interestingly enough both espflash monitor and cargo espflash monitor both work. But espflash write-bin always fails to connect.

@jessebraham
Copy link
Member

I should have a PR soon implementing the various reset strategies now used in esptool.py, so I will update this issue when I have opened a draft and we can do some testing!

@jessebraham
Copy link
Member

I've implemented the retry strategies from esptool.py, there's a draft PR open: #344

I have not tested this much so it's possible there are still issues with it, but seems to be working on my end (not that I ever seem to have issues flashing 😁 ). If anybody here could test out this branch and let me know if it helps that'd be appreciated!

@jessebraham
Copy link
Member

Just bumping this.

@reinismu @Andrew-Collins @senior-cpp-developer if any of you are able to confirm that #344 does or does not resolve your issues that would be very helpful. If I don't hear anything back in a couple weeks, I will likely close this issue and assume that the PR resolves the issues (as I did not experience flashing issues previously, so I'm unable to tell if this helps or not).

@Andrew-Collins
Copy link

Just realised that I wasn't passing through /run/udev to the container, so it had no info about the device.

The ESP32-S3 uses a USB JTAG/serial controller, espflash has a method specifically for these controllers, but had to revert to using the "classic" reset method due to having no info about port.

@senior-cpp-developer it would be interesting to see if this was your problem too.
In the prompt to select the serial port, there should be info about the device, such as below:

❯ /dev/ttyACM0 - USB_JTAG_serial_debug_unit
  /dev/ttyS4
  /dev/ttyS1

If there is no additional info, then for some reason the os/container/espflash is unable to access udev information.

@jessebraham jessebraham removed this from the v2 milestone Jun 24, 2023
@jessebraham jessebraham removed their assignment Jun 27, 2023
@SergioGasquez SergioGasquez linked a pull request Oct 6, 2023 that will close this issue
@SergioGasquez
Copy link
Member

Can anyone affected by this issue check if #487 fixes the issue?

cargo install --git https://github.com/SergioGasquez/espflash --branch fix/resets cargo-espflash espflash

@SergioGasquez SergioGasquez added this to the v3 milestone Oct 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

6 participants