esp32-s3 does not reset after upload

prplz commented 2 years ago

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

[X] I confirm I have checked existing issues, online documentation and Troubleshooting guide.

prplz commented 2 years ago

cc @UnexpectedMaker

UnexpectedMaker commented 2 years ago

@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 commented 2 years ago

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

UnexpectedMaker commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

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

me-no-dev commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

frankcohen commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

me-no-dev commented 2 years ago

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

We can not use the USB-OTG in download mode (so we switch to the integrated CDC+JTAG)
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 commented 2 years ago

@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 commented 2 years ago

@UnexpectedMaker exactly :)

egnor commented 2 years ago

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:

Use a physical USB-to-serial converter chip/module, connected to the ESP32-S3's serial TX and RX lines
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:

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.
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:

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.
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 https://github.com/espressif/esptool/issues/756 and PR https://github.com/espressif/esptool/pull/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 commented 2 years ago

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

egnor commented 2 years ago

@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 commented 2 years ago

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 https://github.com/espressif/arduino-esp32/issues/6762#issuecomment-1183831053, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABUEWMKREROROZRVCZXFXPTVT5QP5ANCNFSM5WDKDUNA . You are receiving this because you were mentioned.Message ID: @.***>

UnexpectedMaker commented 2 years ago

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

Jason2866 commented 2 years ago

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 commented 2 years ago

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)

egnor commented 2 years ago

@Jason2866,

Can you list USB devices when you have it running (on Mac, I think that's ioreg -p IOUSB)? When I flash and install tasmota32s3cdc, it shows up as Espressif USB JTAG/serial debug unit, meaning that it's meaning the hardware USB Serial/JTAG controller, not the USB-OTG controller -- in which case, no surprise that it works.

This makes sense because when I look at Tasmota/boards/esp32s3cdc.json I see

"extra_flags": "-DBOARD_HAS_PSRAM -DARDUINO_USB_MODE=1 -DARDUINO_USB_CDC_ON_BOOT=0 -DARDUINO_USB_MSC_ON_BOOT=0 -DARDUINO_USB_DFU_ON_BOOT=0 -DUSE_USB_CDC_CONSOLE -DESP32_4M -DESP32S3"

and the -DARDUINO_USB_MODE=1 instructs both the Arduino runtime and also Tasmota firmware to use the USB Serial/JTAG controller:

#if ARDUINO_USB_MODE
//#warning **** TasConsole ARDUINO_USB_MODE ****
HWCDC TasConsole;                           // ESP32C3/S3 embedded USB using JTAG interface
bool tasconsole_serial = false;
//#warning **** TasConsole uses HWCDC ****
#else
...

[P.S. I removed a bunch of my previous notes and coalesced them into my summary above, for clarity]

Jason2866 commented 2 years ago

@egnor Will try to find the used device(s) (tomorrow to late now...). I see no drawback to use the USB Serial/JTAG controller for flashing and using as console.

egnor commented 2 years ago

Indeed, the workaround to use the USB Serial/JTAG controller instead of USB-OTG with a serial driver, is fine for some use cases. (Not for my use case in particular, as I wanted to do other things with the USB port besides console.) It would be my starting recommendation for people bumping into this.

frankcohen commented 2 years ago

Thanks Daniel, I’ll see about modifying this, as my board doesn’t have the same TFT display (it has another one, a 240x240 round display). Also, for others, the official Adafruit Feather board definition is at https://github.com/platformio/platform-espressif32/blob/d92c4783ed0ea4a26f3406fc74461e937187b01f/boards/adafruit_feather_esp32s3.json

-Frank

On Jul 13, 2022, at 10:57 PM, Daniel Egnor @.***> wrote:

@frankcohen https://github.com/frankcohen perhaps platformio/platform-espressif32#851 https://github.com/platformio/platform-espressif32/pull/851 will be of interest!

— Reply to this email directly, view it on GitHub https://github.com/espressif/arduino-esp32/issues/6762#issuecomment-1184028008, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABUEWMLBB4SQ5JDCAGJGMZLVT6T3ZANCNFSM5WDKDUNA. You are receiving this because you were mentioned.

Jason2866 commented 2 years ago

@frankcohen The "official" manifest is for the Adafruit ESP32-S3 Feather with STEMMA QT / Qwiic - 8MB Flash No PSRAM is with the knowledge from this thread not the optimal one. For easy flashing a change to use the USBserial/jtag is the way. I dont get it what benefit of tinyuf2 should be. Imho flash space waste. Since many boards manifests are not complete (or wrong) or have unwanted add ons included, we do not use any "official" boards manifest for our project. We define what we need. Big advantage of Platformio, you dont have to use predefined stuff.

frankcohen commented 2 years ago

Thanks for the tips Jason. I plan to create my own board definition. And I'll contribute that under an open source license For right now I'm using the Adafruit board definition. Frank

On Thu, Jul 14, 2022, 11:38 PM Jason2866 @.***> wrote:

@frankcohen https://github.com/frankcohen The "official" manifest is for the Adafruit ESP32-S3 Feather with STEMMA QT / Qwiic - 8MB Flash No PSRAM is with the knowledge from this thread not the optimal one. For easy flashing a change to use the USBserial/jtag is the way. I dont get it what benefit of tinyuf2 should be. Imho flash space waste. Since many boards manifests are not complete (or wrong) or have unwanted add ons included, we do not use any "official" boards manifest for our project. We define what we need. Big advantage of Platformio, you dont have to use predefined stuff.

— Reply to this email directly, view it on GitHub https://github.com/espressif/arduino-esp32/issues/6762#issuecomment-1185225614, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABUEWMOWFWBM73KS4W6JPTDVUEBMVANCNFSM5WDKDUNA . You are receiving this because you were mentioned.Message ID: @.***>

Jason2866 commented 2 years ago

@egnor

ioreg -p IOUSB
+-o Root  <class IORegistryEntry, id 0x100000100, retain 27>
  +-o AppleT8103USBXHCI@01000000  <class AppleT8103USBXHCI, id 0x100000308, registered, matched, active, busy 0 (170 ms), $
  | +-o PSSD T7@01200000  <class IOUSBHostDevice, id 0x10000082b, registered, matched, active, busy 0 (157 ms), retain 173$
  +-o AppleT8103USBXHCI@00000000  <class AppleT8103USBXHCI, id 0x1000002ad, registered, matched, active, busy 0 (104789 ms$
    +-o HP USB-C Dock G5@00200000  <class IOUSBHostDevice, id 0x100000716, registered, matched, active, busy 0 (493 ms), r$
    | +-o USB5734@00230000  <class IOUSBHostDevice, id 0x10000076d, registered, matched, active, busy 0 (15 ms), retain 10$
    | +-o USB 10/100/1000 LAN@00240000  <class IOUSBHostDevice, id 0x1000007ca, registered, matched, active, busy 0 (478 m$
    +-o HP USB-C Dock G5@00100000  <class IOUSBHostDevice, id 0x100000747, registered, matched, active, busy 0 (104695 ms)$
      +-o USB Audio@00120000  <class IOUSBHostDevice, id 0x1000007a0, registered, matched, active, busy 0 (417 ms), retain$
      +-o HP USB-C Dock G5@00150000  <class IOUSBHostDevice, id 0x1000007b3, registered, matched, active, busy 0 (402 ms),$
      +-o USB2734@00130000  <class IOUSBHostDevice, id 0x1000283f6, registered, matched, active, busy 0 (692 ms), retain 3$
        +-o Jabra PRO 9470@00131000  <class IOUSBHostDevice, id 0x100028412, registered, matched, active, busy 0 (138 ms),$
        +-o USB 2.0 Hub [Safe]@00133000  <class IOUSBHostDevice, id 0x10002841d, registered, matched, active, busy 0 (345 $
        | +-o Storage Media@00133100  <class IOUSBHostDevice, id 0x100028456, registered, matched, active, busy 0 (77 ms),$
        | +-o IOUSBHostDevice@00133400  <class IOUSBHostDevice, id 0x100028461, registered, matched, active, busy 0 (258 m$
        | +-o USB Receiver@00133200  <class IOUSBHostDevice, id 0x10002846b, registered, matched, active, busy 0 (213 ms),$
        +-o USB JTAG/serial debug unit@00132000  <class IOUSBHostDevice, id 0x10002842b, registered, matched, active, busy$

egnor commented 2 years ago

+-o USB JTAG/serial debug unit@00132000 <class IOUSBHostDevice, id 0x10002842b, registered, matched, active, busy

Yep, that's the USB Serial/JTAG hardware. Makes sense 🌈

VojtechBartoska commented 2 years ago

Do you still face this @prplz on the master Branch?

prplz commented 2 years ago

Still present at master (d22bcb7) with um_tinys3

taf2 commented 2 years ago

Wondering if anyone has um_tinys3 uploads working yet from platformio ? If so what have you put into your platformio.ini file to get this working? @UnexpectedMaker love your boards but haven't yet been able to get a tinys3 working... hope you keep making the tinypico's

Jason2866 commented 2 years ago

@taf2 Use latest Platformio release. The board is there. So

platform = espressif32 @ 5.2.0
board = um_tinys3

taf2 commented 2 years ago

@Jason2866 oh nice this appears to get it to start uploading but still failed for me at about 95% - this is an improvement!

Here's error details: https://gist.github.com/taf2/cf0cc03d9be63b16cafcd378e9ae90e5

Here's project files: https://github.com/taf2/tinypico-fridge-alarm

Jason2866 commented 2 years ago

@taf2 You have a problem with your USB port. Use a other USB Cable (shorter / better). If this does not help use a different USB port. This issue has nothing to do with the board nor Platformio.

You run probably in this issue https://github.com/espressif/esptool/issues/712

I do not run in this issue since the M1 Air is connected via a HP G5 USB-C Dockingstation.

CURRENT: upload_protocol = esptool
Looking for upload port...
Using manually specified: /dev/cu.usbmodem13201
Uploading .pio/build/tasmota32s3cdc-cam/firmware.bin
esptool.py v4.3
Serial port /dev/cu.usbmodem13201
Connecting...
Chip is ESP32-S3 (revision v0.1)
Features: WiFi, BLE
Crystal is 40MHz
MAC: 68:b6:b3:20:b1:9c
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 0x00157fff...
Flash params set to 0x024f
Compressed 13408 bytes to 9308...
Writing at 0x00000000... (100 %)
Wrote 13408 bytes (9308 compressed) at 0x00000000 in 0.3 seconds (effective 321.3 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 333.6 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 494.7 kbit/s)...
Hash of data verified.
Compressed 1340752 bytes to 937528...
Writing at 0x00010000... (1 %)
Writing at 0x00016641... (3 %)
Writing at 0x00023a36... (5 %)
Writing at 0x00027d28... (6 %)
Writing at 0x0002d185... (8 %)
Writing at 0x000368c8... (10 %)
Writing at 0x0003ea49... (12 %)
Writing at 0x00046b56... (13 %)
Writing at 0x0004ecb0... (15 %)
Writing at 0x000596ed... (17 %)
Writing at 0x0005fbee... (18 %)
Writing at 0x00064f95... (20 %)
Writing at 0x0006a109... (22 %)
Writing at 0x0006f2c3... (24 %)
Writing at 0x00074381... (25 %)
Writing at 0x0007932d... (27 %)
Writing at 0x0007e224... (29 %)
Writing at 0x00083688... (31 %)
Writing at 0x00088c5c... (32 %)
Writing at 0x0008e240... (34 %)
Writing at 0x00093cfc... (36 %)
Writing at 0x00099654... (37 %)
Writing at 0x0009f01b... (39 %)
Writing at 0x000a4071... (41 %)
Writing at 0x000a8ce4... (43 %)
Writing at 0x000addce... (44 %)
Writing at 0x000b2afb... (46 %)
Writing at 0x000b78d8... (48 %)
Writing at 0x000bc6cd... (50 %)
Writing at 0x000c1398... (51 %)
Writing at 0x000c62a7... (53 %)
Writing at 0x000cbc42... (55 %)
Writing at 0x000d10e5... (56 %)
Writing at 0x000d6cb9... (58 %)
Writing at 0x000dc135... (60 %)
Writing at 0x000e0ffd... (62 %)
Writing at 0x000e5f9e... (63 %)
Writing at 0x000eafb9... (65 %)
Writing at 0x000eff24... (67 %)
Writing at 0x000f6309... (68 %)
Writing at 0x000fb5d8... (70 %)
Writing at 0x001005ac... (72 %)
Writing at 0x0010591c... (74 %)
Writing at 0x0010ab27... (75 %)
Writing at 0x001104b2... (77 %)
Writing at 0x00115926... (79 %)
Writing at 0x0011a7c4... (81 %)
Writing at 0x0011f883... (82 %)
Writing at 0x001249a1... (84 %)
Writing at 0x00129e07... (86 %)
Writing at 0x0012f1e1... (87 %)
Writing at 0x00134ffe... (89 %)
Writing at 0x0013a476... (91 %)
Writing at 0x0013f57c... (93 %)
Writing at 0x00144ce5... (94 %)
Writing at 0x0014a3b2... (96 %)
Writing at 0x0014fe72... (98 %)
Writing at 0x00155d8f... (100 %)
Wrote 1340752 bytes (937528 compressed) at 0x00010000 in 16.3 seconds (effective 656.6 kbit/s)...
Hash of data verified.

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

taf2 commented 2 years ago

Ah you know what i think this is my platformio being out of date.

pio --version
PlatformIO Core, version 6.1.4
taf2~/work/arduino/tinypico-fridge-alarm (main) * > which pio
/usr/local/bin/pio
taf2~/work/arduino/tinypico-fridge-alarm (main) * > vi Makefile
taf2~/work/arduino/tinypico-fridge-alarm (main) * > ls -lh /usr/local/Cellar/platformio/
total 0
drwxr-xr-x  8 taf2  admin   256B Oct 20  2021 5.2.2

So i've been avoiding brew update (because painful) and just running pio upgrade... but it seems like that was not upgrading the actual core platform io files... so this means i had out of date files...

however same issue after upgrading things... that said the cable does not seem to be the issue because I can use it just fine with the tinypico usbc version... i'll get another usbc cable and try on a different computer

Jason2866 commented 2 years ago

The cable can work with other boards, transfer speed and protocol is different when CDC USB modem is used. For most Apple users having this problem a USB Hub does solve. Btw. using Platformio with VSC is way more nice.

taf2 commented 2 years ago

Yeah, I am not much of a VSC fan... I am maybe too old and just like to use vim when/wherever possible (for better or worse) - this is definitely an older USBC cable got it from i think pixel 1 phone... will try on my newer macbook with usbc to usbc cable next and then a usbc hub. Really appreciate the help in jumping in on this thread very amazing and very helpful thank you!

Jason2866 commented 2 years ago

Your welcome, please tell me your result.

taf2 commented 2 years ago

same issue with different usbc cable new one from apple store... i'll try a different tinys3 next and see if it's the board...

Jason2866 commented 2 years ago

As i wrote before, if it is not the cable it is a Mac related problem. I highly doubt the board is faulty.

taf2 commented 2 years ago

@Jason2866 yeah i would imagine it's Mac related as well... except i just got everything running on windows environment and have the exact same error with different USBC cable as well...

i'll go to store tomorrow and buy a few different types of cables... but still unable to get tinys3 working where tinypico always has worked...

taf2 commented 2 years ago

I have 3 tinys3's and just got 1 to work... so definitely seems like 2 out 3 boards are bad... I'll take high resolution image of boards... but 1 board out of 3 worked same usbc cable on windows... i'll test on linux and mac tomorrow.

UnexpectedMaker commented 2 years ago

I have 3 tinys3's and just got 1 to work... so definitely seems like 2 out 3 boards are bad... I'll take high resolution image of boards... but 1 board out of 3 worked same usbc cable on windows... i'll test on linux and mac tomorrow.

Sorry, this cant be board specific - 2 bad boards out of 3. There is nothing that could be bad at the board level. It's native USB and internal Flash.

If the boards were bad they would not enumerate. You would not be able to erase them.

What OS are you using?

Have you tried putting it into download mode before flashing it?

taf2 commented 2 years ago

@UnexpectedMaker big fan so to clarify this is just looking for advice here... figured video to share for context is better then trying to explain via words... can provide as much details as needed here's unlisted yt videos:

HD revisions hopefully ready soon. I have one more tinys3 board i can run through the same tests and share...

UnexpectedMaker commented 2 years ago

But what you are doing wont work.....
The boards that are not flashed, do not have the CDC running, so they have no USB serial device present to flash. You need to put them into download mode first to flash them.

The board that is working, has the CDC running, so presents a USB serial device to be re-flashed.

Can you get on my discord server, for faster support iteration?

Works with TinyPICO makes no difference as the TinyPICO doesn't have native USB, and instead has a seperate Serial UART, so is always present to be flashed. Though sure, should rule out your cable.

UnexpectedMaker commented 2 years ago

On your Mac video, that 3rd board is not in download mode - it's looking for the wrong USB serial port - you can see that on the port it's trying to flash. Put it into download mode, then try to flash it.

The first flash in Arduino or PIO has to be done via download mode as the boards ship wth CP on them, which presents a non-flashable USB device to windows as it's a mass storage device.

The 96%'er - use esptool to erase the flash, then try to flash it again. Also, just try to flash a basic hello world sketch on it.

It could have bad internal flash... but highly unlikely. I've never see a board fail at 96% due to bad flash - usually fails at 2 or 3%, but I want to see if it can erase.

UnexpectedMaker commented 2 years ago

But what you are doing wont work..... The boards that are not flashed, do not have the CDC running, so they have no USB serial device present to flash. You need > to put them into download mode first to flash them.

The board that is working, has the CDC running, so presents a USB serial device to be re-flashed.

Ok, ignore the above as I can now see in the Mac video, 2 boards are enumerating in download mode, but your 3rd board (that failed in both) isn't, so you have to manually put it into download mode to flash it the first time.

Jason2866 commented 2 years ago

@UnexpectedMaker With a fully erased flash it is no problem to flash via CDC. There is no need for any driver on the device. Esptool.py puts the device in flashing mode (without the need of pressing a button) and flashes. Maybe this behaviour is not consistent with all OS. But for MacOS it does work this way. I have different S3 CDC devices and it works always. The S3 issue is that it is staying in bootloader mode and needs a manual reset to start.

espressif / arduino-esp32