esp32-s3 does not reset after upload

[prplz]

Board

esp32s3

Device Description

esp32s3 devkitc n8r8

Hardware Configuration

Native USB port plugged into computer, serial convert USB port not plugged in.

Version

v2.0.3

IDE Name

Arduino IDE, Platformio

Operating System

Windows 10, MacOS

Flash frequency

80MHz

PSRAM enabled

no

Upload speed

921600

Description

Uploading a sketch over usb otg should reset the chip after upload, but it does not.

Other Steps to Reproduce

• Select USB mode = USB-OTG, USB CDC on boot = enabled, Upload mode = USB OTG CDC.
• Upload sketch
• Board correctly resets into download mode using 1200 baud and uploads the sketch
• Board does not reset and run the sketch as it should, instead staying in download mode. Here you have to press the reset button manually. On S2 the board resets and runs the sketch after upload with no manual intervention.

Tested on s3 devkitc and all UnexpectedMaker s3 boards.

Notes:

• No esptool commands reset the board, on the s2 it does reset
• Esptool doesn't detect when the board was put into bootloader using IO0 as it does on s2 (WARNING: ESP32-S2FNR2 chip was placed into download mode using GPIO0)
• USB mode and upload mode set to hardware CDC resets as expected

I have checked existing issues, online documentation and the Troubleshooting Guide

• I confirm I have checked existing issues, online documentation and Troubleshooting guide.

[prplz]

cc @UnexpectedMaker

[UnexpectedMaker]

@me-no-dev I assume this is not the intended behaviour? And the S3 boards should reset after flashing them like the S2 boards do right?

[me-no-dev]

@UnexpectedMaker not if you are using TinyUSB while booted. It works if the integrated CDC+JTAG is used, but the other USB no.

[UnexpectedMaker]

@UnexpectedMaker not if you are using TinyUSB while booted. It works if the integrated CDC+JTAG is used, but the other USB no.

Hmm, but it works correctly with the S2, so why not with the S3? It's really confusing people - they think their boards didn't flash, as no other ESP32 has this issue (original, S2, C3 etc) - so people are complaining about HW faults.

If we use CDC+JTAG, then the board doesn't enumerate with the custom device name, which also confuses people, so it seems like the S3 has the worst of both situations, rather than any improvement in either.

How do we get this behaviour changed?

[sukesh-ak]

Yes this has become a painful issue. Have tested from Arduino and ESP-IDF with same behaviour.

This also means you have to reconnect serial monitor after every firmware upload for proper update.

[VojtechBartoska]

This seems worth improving and documenting as well? cc @me-no-dev & @pedrominatel

[me-no-dev]

How do we get this behaviour changed?

Surely if we could we would have :) I went through ROM code and everything, but could not figure out what is preventing the board/download mode to reboot the firmware. When booting into download from TinyUSB, we first stop TinyUSB, then init CDC+JTAG and then reboot into download, so in reality it should have been the same as rebooting from CDC+JTAG, but it is not. We might find a way in the future, but this has taken too much resources already as it is.

[frankcohen]

This is pain, I'm having to use the Boot pin after every upload. And that has the side effect of closing Arduino IDE Serial Monitor randomly.

I'm glad to volunteer my hours with direction. Just tell me what to do.

Background: I'm working on the open-source Reflections wrist watch project, including an ESP32-S3-Mini based main board. I'm building this using the Adafruit Feather ESP32-S3 as a reference and using their Arduino IDE 12.3.1 board definition "Adafruit Feather ESP32-S3 No PSRAM". I'm using ESP32 version 2.0.3, installed through the Boards Manager. Repository for my project is at https://github.com/frankcohen/ReflectionsOS/tree/main/Devices/Hoober

[sukesh-ak]

@frankcohen
As a side note you should check out UM boards for S3.
https://unexpectedmaker.com/shop

[frankcohen]

Thanks, the UM boards look great. I'd be glad for UM to carry my board too. I will open-source the board. -Frank

[boberace]

Not sure if this is helpful but ... My ESP32-S3-DevKitC-1-N8R2 does reset after upload if I use the UART USB jack but it will not reset after upload when using the OTG USB jack UNLESS I upload right after I erase flash.

My UM Feather S2 does reset after upload. My UM TinyS3 does not reset after upload.

[UnexpectedMaker]

@me-no-dev Is this issue caused by security advisory AR2022-004 ?

[me-no-dev]

@UnexpectedMaker yes and no. You can think of this as two separate issues:

1. We can not use the USB-OTG in download mode (so we switch to the integrated CDC+JTAG)
2. When we switch to CDC+JTAG and reboot into Download Mode, chip is not reset after the new firmware is flashed (what we are discussing in this thread)

AR2022-004 talks about issue 1

[UnexpectedMaker]

@me-no-dev So if issue 1 is resolved, then you could use USB-OTG and not have to switch to CDC, bypassing issue 2? So that would also fix this problem on newer silicon?

[me-no-dev]

@UnexpectedMaker exactly :)

[egnor]

My understanding [EDITED based on subsequent investigations]

Background

There are multiple ways to connect from a a host (Mac/PC) USB port to an ESP32-S3 for bootloading (download) and serial terminal purposes:

1. Use a physical USB-to-serial converter chip/module, connected to the ESP32-S3's serial TX and RX lines
2. Use the ESP32-S3's onboard USB controller, wire the USB port directly to the ESP32-S3.

If using option (1) there is no problem. (For example this is the UART USB jack on the ESP32-S3 DevKit board.) However, that requires an extra part and it's otherwise nice to use the integrated USB controller. So, let's assume option (2). This requires configuring the ESP32-S3 to act as a serial port device. There are again multiple ways to do that:

1. Use the ESP32-S3's internal USB-OTG (On The Go) peripheral, which supports acting as a general purpose USB host or device (the bidirectionality is what makes it "On The Go"); in software, set the peripheral up to act as a USB device, and implement the USB CDC ("Communications Device Class", aka serial port) protocol, and thus the device shows up as a serial port to the host.
2. Use the ESP32-S3's internal USB Serial/JTAG peripheral, which is a separate special purpose USB controller that only supports USB CDC (serial port) and JTAG (debugging port, not important here) protocols.

Using the dedicated USB Serial/JTAG controller is simpler for software, since the hardware takes care of most of the details of USB. However, the USB-OTG controller is more general, allowing other device classes (such as mass storage) in addition to being a serial port.

Importantly, the bootloader (used to upload code) and the application (which wants to Serial.print to a console) might make different choices about which controller to use. The Arduino platform, for example, tends to use TinyUSB, a software USB stack that expects a fully general USB controller, which would imply the USB-OTG controller.

Issues

So far this is all lovely but now there are some wrinkles.

As @me-no-dev noted above, the bootloader cannot use the USB-OTG controller. This is related to a spot of confusion over one-time-programmable EFUSE bits as described in security advisory AR2022. Basically, for many ESP32-S3 parts, bootloader USB-OTG access is permanently disabled.

So, the bootloader uses the USB Serial/JTAG controller instead (if allowed). This works just fine and allows the flash to be programmed in the normal way. HOWEVER, it is observed that sometimes the bootloader is unable to exit into the application, and a manual reset is required to start the app.

This appears to happen if the bootloader (download mode) is entered (by reboot-to-bootloader typically triggered by DTR/RTS wiggles) FROM an application using the USB-OTG controller (not hardware USB Serial/JTAG), which is the Arduino runtime's default.

Per @me-no-dev's comment above, the reasons for this are not entirely understood, but it's thought to be something about switching between the two controllers?

Workarounds

There are two known ways to work around this:

1. After loading code, use a full hardware reset (probably a button) to launch the app. This fully resets the board and skips the USB Serial/JTAG controller, avoiding issues with switching. However it's inconvenient, impossible without physical access, and disruptive to port connectivity.
2. In the application, use the USB Serial/JTAG controller instead of the USB-OTG controller. This limits flexibility (can't be a mass storage device at the same time) and makes the port show up as a generic "Espressif USB JTAG/serial debug unit".

To switch the Arduino runtime to the USB Serial/JTAG controller (workaround (ii)):

• In the Arduino IDE, select Tools > USB Mode > Hardware CDC and JTAG (pictured above).
• With arduino-cli, use --build-property=build.usb_mode=1 on the command line (untested).
• With platformio, use build_flags = -DARDUINO_USB_MODE=1 in platformio.ini.
  NOTE, you may need to also add -DARDUINO_USB_CDC_ON_BOOT=0 OR -DARDUINO_USB_CDC_ON_BOOT=1 depending on platform version; see discussion in comments below.
• If using ESP-IDF and not Arduino, select ESP_CONSOLE_USB_SERIAL_JTAG in menuconfig.

Both workarounds are somewhat unfortunate, which is why this bug exists and people are grumpy. As a third approach, some people have had luck with patches to esptool, see comments below for discussion and links, but this is not yet a confirmed fix.

Investigation notes

As noted above, success/failure seems to be triggered not by what app we're loading but by what app was running before resetting to the bootloader:

• run OTG-using app, reset to run, flash JTAG/Serial-using app => loads but does NOT run
• reset to start JTAG/Serial-using app, flash the same app again => loads and DOES run
• flash OTG-using app => loads and DOES run right away!
• flash OTG-using app again => loads and does NOT run
• reset to run OTG-using app, flash OTG-using app again => loads and does NOT run
• reset to run OTG-using app, flash JTAG/Serial-using app => loads but does NOT run
• reset to start JTAG/Serial-using app, flash OTG-using app => loads and DOES run

So somehow, when resetting back to the bootloader, a running OTG-using app leaves state in the system that prevents the bootloader from jumping to start ANY program it loads. Maybe the reboot-to-bootloader code in the OTG-based driver is somehow doing things slightly wrong?

For reference, the USB Serial/JTAG controller can be distinguished from the USB-OTG controller externally; it shows up as "Espressif USB JTAG/serial debug unit" with VID:PID 303A:1001.

Rebooting from app to bootloader and bootloader to app (the path that fails) is generally managed by wiggling DTR and RTS serial control lines -- this is the "Hard resetting via RTS pin..." message from in esptool.py (with the default --after=hard_reset). Of course these "pins" are purely virtual in this case, contained within the emulated serial port.

The USB Serial/JTAG controller manages DTR/RTS wiggle detection directly. This is described in section 30.3.2 in the technical reference:

Here is the further discussion in section 30.4.2:

The reset-to-app code in esptool.py does this, assuming DTR=0 and RTS=0 on entry:

    def hard_reset(self):
        if self.uses_usb():
            self._check_if_can_reset()

        print("Hard resetting via RTS pin...")
        self._setRTS(True)  # EN->LOW
        if self.uses_usb():
            # Give the chip some time to come out of reset,
            # to be able to handle further DTR/RTS transitions
            time.sleep(0.2)
            self._setRTS(False)
            time.sleep(0.2)
        else:
            self._setRTS(False)

(Tangent: self.uses_usb() is currently broken; see bug espressif/esptool#756 and PR espressif/esptool#757. Fixing it doesn't help this issue, though.)

DTR and RTS can be wiggled manually for testing with miniterm, with ^T^D and ^T^R respectively. After reproducing this problem (successfully flashing an app, but failing to reboot-to-app), we can see this:

% python -m serial.tools.miniterm /dev/ttyACM0 115200
--- Miniterm on /dev/ttyACM0  115200,8,N,1 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
--- RTS inactive ---  [[ note: ^T^R was pressed here ]]
--- DTR inactive ---  [[ ^T^D was pressed here ]]
--- RTS active ---  [[ ^T^R ]]
ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0x15 (USB_UART_CHIP_RESET),boot:0x0 (DOWNLOAD(USB/UART0))
Saved PC:0x40041a76
waiting for download

So it does reboot on wiggle, but the waiting for download indicates it ended up back in the bootloader. It's as if the "download flag" was not successfully reset during the RTS=0 DTR=0 point. If I go through the other sequence to explicitly set the "download flag", I get identical output:

--- RTS inactive ---
--- DTR active ---
--- RTS active ---
--- DTR inactive ---
ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0x15 (USB_UART_CHIP_RESET),boot:0x0 (DOWNLOAD(USB/UART0))
Saved PC:0x40041a76
waiting for download

When reboot-to-app does work (after running the esp-idf/examples/system/console/basic sample app built with ESP_CONSOLE_USB_SERIAL_JTAG), we can see both of the USB/Serial controller's DTR/RTS wiggle sequences work correctly. Going from bootloader to app:

waiting for download
--- DTR inactive ---
--- RTS inactive ---
--- RTS active ---
ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0x15 (USB_UART_CHIP_RESET),boot:0x8 (SPI_FAST_FLASH_BOOT)
Saved PC:0x400428a0
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fce3810,len:0x113c
load:0x403c9700,len:0xa4c
load:0x403cc700,len:0x2af0
entry 0x403c9898
 ... blah blah blah ...
Type 'help' to get the list of commands.
Use UP/DOWN arrows to navigate through command history.
Press TAB when typing command name to auto-complete.
Your terminal application does not support escape sequences.

Line editing and history features are disabled.
On Windows, try using Putty instead.
esp32s3>

Going from app back to bootloader:

esp32s3> --- RTS inactive ---
--- DTR active ---
--- RTS active ---
--- DTR inactive ---
ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0x15 (USB_UART_CHIP_RESET),boot:0x0 (DOWNLOAD(USB/UART0))
Saved PC:0x4037c14a
waiting for download

Note the boot:0x8 (SPI_FAST_FLASH_BOOT) instead of boot:0x0 (DOWNLOAD(USB/UART0)).

As a final note, fixing uses_usb() detection creates a problem with false errors:

WARNING: ESP32-S3 chip was placed into download mode using GPIO0.
esptool.py can not exit the download mode over USB. To run the app, reset the chip manually.
To suppress this note, set --after option to 'no_reset'.
*** [upload] Error 1

Apparently GPIO_STRAPPING gets zeroed out by internal resets, including resets triggered by DTR/RTS wiggles detected by the USB Serial/JTAG peripheral. That triggers the false locked-into-bootloader alert from esptool. (In actual fact if the error is bypassed, esptool can reboot into app just fine in that scenario.)

Esptool detects another method of software reboot-into-bootloader (RTC_CNTL_FORCE_DOWNLOAD_BOOT) to avoid some false alarms, but the USB Serial/JTAG peripheral doesn't use that mechanism. USB Serial/JTAG triggered reboot does have a reason code in RTC_CNTL_RTC_RESET_STATE_REG, but esptool.py's initial reset always leaves that reason code in place, even when the system is locked into the bootloader. So that's not a useful discriminator. With uses_usb() broken (as it currently is at head), at least that check is disabled and doesn't get in the way...

The main relevance of the above is that there seems to be a bunch of subtle/hidden chip state controlling whether or not the system starts in the bootloader or jumps to the app. The logic is hard to observe, hidden in the obscurities of the closed-source ROM, and thus hard to debug from outside.

[frankcohen]

Just a note of appreciation to Egnor, thank you. And a question, have you seen JTAG with platform IO and esp32s3 working?

[egnor]

@frankcohen wrote:

Just a note of appreciation to Egnor, thank you. And a question, have you seen JTAG with platform IO and esp32s3 working?

I have not tried! I am curious about it but figured I'd open one can of worms at a time. If you do try, or have tried, I'd like to know how it goes.

[frankcohen]

I'll let you know. The bigger problem to solve first is getting Platform IO to recognize the Adafruit Feather ESP32-S3 board definition file. That's next.

…

On Wed, Jul 13, 2022, 5:55 PM Daniel Egnor ***@***.***> wrote: @frankcohen <https://github.com/frankcohen> wrote: Just a note of appreciation to Egnor, thank you. And a question, have you seen JTAG with platform IO and esp32s3 working? I have not tried! I am curious about it but figured I'd open one can of worms at a time. If you do try, or have tried, I'd like to know how it goes. — Reply to this email directly, view it on GitHub <#6762 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABUEWMKREROROZRVCZXFXPTVT5QP5ANCNFSM5WDKDUNA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[UnexpectedMaker]

@egnor This is great investigative work Daniel! Thanks very much for the awesome effort.

[Jason2866]

I'll let you know. The bigger problem to solve first is getting Platform IO to recognize the Adafruit Feather ESP32-S3 board definition file. That's next.

@frankcohen Thats not complicated. Just create a folder boards in the root folder of your project. Add the boards.json manifest there. Example

[Jason2866]

Mhhh, just connected my S3 board via GPIO 19/20 (inbuilt "USBModem"). Just worked, flashed and started flashed firmware without doing anything (Tasmota do not use TinyUSB).

Compiling tasmota32s3cdc and flashing Tasmota via PlatformIO

esptool.py v3.3.1
Flash params set to 0x023f
Wrote 0x1502b0 bytes to file /Users/hans/Git/Tasmota/.pio/build/tasmota32s3cdc/firmware.factory.bin, ready to flash to offset 0x0
bin_map_copy([".pio/build/tasmota32s3cdc/firmware.bin"], [".pio/build/tasmota32s3cdc/firmware.elf"])
map_gzip([".pio/build/tasmota32s3cdc/firmware.bin"], [".pio/build/tasmota32s3cdc/firmware.elf"])
Configuring upload protocol...
AVAILABLE: cmsis-dap, esp-bridge, esp-builtin, esp-prog, espota, esptool, iot-bus-jtag, jlink, minimodule, olimex-arm-usb-ocd, olimex-arm-usb-ocd-h, olimex-arm-usb-tiny-h, olimex-jtag-tiny, tumpa
CURRENT: upload_protocol = esptool
Looking for upload port...
Using manually specified: /dev/cu.usbmodem13201
Uploading .pio/build/tasmota32s3cdc/firmware.bin
esptool.py v3.3.1
Serial port /dev/cu.usbmodem13201
Connecting...
Chip is ESP32-S3
Features: WiFi, BLE
Crystal is 40MHz
MAC: f4:12:fa:43:62:5c
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 460800
Changed.
Configuring flash size...
Flash will be erased from 0x00000000 to 0x00003fff...
Flash will be erased from 0x00008000 to 0x00008fff...
Flash will be erased from 0x0000e000 to 0x0000ffff...
Flash will be erased from 0x00010000 to 0x00150fff...
Flash params set to 0x023f
Compressed 13696 bytes to 9532...
Writing at 0x00000000... (100 %)
Wrote 13696 bytes (9532 compressed) at 0x00000000 in 0.3 seconds (effective 367.4 kbit/s)...
Hash of data verified.
Compressed 3072 bytes to 129...
Writing at 0x00008000... (100 %)
Wrote 3072 bytes (129 compressed) at 0x00008000 in 0.1 seconds (effective 463.0 kbit/s)...
Hash of data verified.
Compressed 8192 bytes to 47...
Writing at 0x0000e000... (100 %)
Wrote 8192 bytes (47 compressed) at 0x0000e000 in 0.1 seconds (effective 611.9 kbit/s)...
Hash of data verified.
Compressed 1311408 bytes to 922312...
Writing at 0x00010000... (1 %)
Writing at 0x00016e7e... (3 %)
- snip
Writing at 0x0014e4f8... (100 %)
Wrote 1311408 bytes (922312 compressed) at 0x00010000 in 15.2 seconds (effective 691.1 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...
=============================== [SUCCESS] Took 55.03 seconds ===============================

Environment     Status    Duration
--------------  --------  ------------
tasmota32s3cdc  SUCCESS   00:00:55.029
=============================== 1 succeeded in 00:00:55.029 ===============================

NO button or strapping pin used.

USBModem-console connected after the message Hard resetting via RTS pin...

00:00:00.001-289/21 CMD: Using USB CDC
00:00:00.001-294/22 HDW: ESP32-S3 (PSRAM)
00:00:00.025-292/21 UFS: FlashFS mounted with 2088 kB free
00:00:00.044 CFG: Loaded from File, Count 6

standard Tasmota boot message!

Tasmota website Infopage. Device started normal. Usb uart reset digital core

My used env to cover the settings of my S3 board (using the standard Tasmota esp32s3cdc boards manifes)

[env:tasmota32s3cdc]
upload_port             = /dev/cu.usbmodem13201
board_upload.flash_size = 8MB
board_upload.maximum_size = 8388608
board_upload.arduino.flash_extra_images =
board_build.partitions  = partitions/esp32_partition_app2944k_fs2M.csv
extends                 = env:tasmota32s3
board                   = esp32s3cdc

My build system is a Mac M1 Air, S3 connected via a HP USB-C Docking Station (G5)

[FunDeckHermit]

FWIW, I think I would agree with @UnexpectedMaker on the expectation that if ESP32-S2 could be re-programmed without requiring a physical reset, ESP32-S3 should be capable of that as well is.

If esptool fix linked above doesn't resolve the issue, we can explore other possible solutions. For example, Arduino-esp32 could clear the "force download mode bit" using esptool write_reg functionality, or we could even include the necessary changes in the next ROM code revision.

espressif/esptool#970 linked by @Jason2866 is an unrelated (although similar-sounding) issue which shouldn't block this one.

Wouldn't it be possible to just invoke the RUN_USER_CODE command (found in the stub loader)?

Edit: It looks like the ESP32-S3 would support it, ESPtool however prevents it from executing on this type of chip:
https://github.com/espressif/esptool/blob/2b0ec7a0a3f7f285157132722f32b5971fb8ebac/esptool/loader.py#L1514

[Jason2866]

@me-no-dev This should be fixed with latest development esptool.py. There is a new reset way introduced WDT RTC reset. espressif/esptool@8298cdc
In my tests the S2 and S3 where successfully reseted this way.

[radimkarnis]

@Jason2866 we haven't released a dev release containing that commit yet, so it's only available on master for now.

It is a potential fix for this and other USB-related resets in Arduino, but I haven't tested that yet. Thanks for looking into it and for confirming it works!

[Jason2866]

@radimkarnis Thx for the fix! Already ported in my Tasmota Esp Flasher. Now the S2 / S3 manual reset is history :-)

[me-no-dev]

@radimkarnis if you do not forget, please ping us here when the fix makes it to IDF 5.3

[Jason2866]

The updated esptool.py is used in develop branch of pioarduino (community Platformio fork, in pioarduino branch develop Arduino branch master is used).
To use change your platform setting to
platform = https://github.com/pioarduino/platform-espressif32.git#develop

EDIT: pioarduino Arduino release core 3.0.7 uses the new esptool.py with WDT RTC

[wuast94]

when i do this i get

*** [.pio\build\adafruit_matrixportal_esp32s3\partitions.bin] Source `partitions-8MB-tinyuf2.csv' not found, needed by target `.pio\build\adafruit_matrixportal_esp32s3\partitions.bin'. 

my platform.ini

[env:adafruit_matrixportal_esp32s3]
platform = https://github.com/pioarduino/platform-espressif32.git#develop
board = adafruit_matrixportal_esp32s3
framework = arduino

[Jason2866]

Seems the name for the partitions.csv has changed. No one provided a PR for this change.

[wuast94]

i searched for this partition file but didnt find anything sadly

[Jason2866]

Yes, because it is not correct in the Platformio/pioarduino boards.manifest.
The boards.json are a mess. Wrong ones provided. Changes done in Arduino not there.
I can't maintain this part. Todo correctly needs to have every board. Even when it will be still a mess. Boards are sold with same name and different Flash / PSRAM size and type...
See README from the repo pioarduino

Issues with boards (wrong / missing). All issues caused from boards will not be fixed from the maintainer(s). A PR needs to be provided to solve.

[wuast94]

can u point me what i have to do to get it working? i tried diffrent partiotion.csv files i found for the board but none of them worked, the upload works but then i get an io error.

but thanks for that insight, i now understand why its always a **** to work with such boards/projects

[Jason2866]

@wuast94 Fix this boards.json https://github.com/pioarduino/platform-espressif32/blob/develop/boards/adafruit_matrixportal_esp32s3.json
The correct entry (I think) should be tinyuf2-partitions-8MB.csv

The Arduino change was done with this PR #8894

Would be very happy if a volunteer is providing a PR in pioarduino fork whenever a change for boards is done in this repo. Speaking as maintainer of pioarduino

[wuast94]

@Jason2866 testet it local and now it compiles but fail with resetting:

Wrote 935424 bytes (617112 compressed) at 0x00010000 in 8.2 seconds (effective 911.8 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting with RTC WDT...

A serial exception error occurred: Cannot configure port, something went wrong. Original message: OSError(22, 'The I/O operation has been aborted because of either a thread exit or an application request.', None, 995)
Note: This error originates from pySerial. It is likely not a problem with esptool, but with the hardware connection or drivers.
For troubleshooting steps visit: https://docs.espressif.com/projects/esptool/en/latest/troubleshooting.html

i will create the pr but think it wouldnt make much sense if we have this problem?

the flash was successfull and i can see in terminal that it works, its just the reset not working, im using the develop branch

[Jason2866]

@wuast94 I think you have a general problem with the port. Anyways the PR for the boards.json is not related to this.