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

Restart in bootmode via software not work when USB cable connected directly to PC #10204

Open
1 task done
rafaelgerges opened this issue Aug 19, 2024 · 14 comments
Open
1 task done
Labels
Type: Question Only question

Comments

@rafaelgerges
Copy link

rafaelgerges commented Aug 19, 2024

Board

ESP32-S3-WROOM-1-N16R8

Device Description

Plain module ESP32-S3-WROOM-1-N16R8 in a custom PCB.

Hardware Configuration

GPIO 19 and 20 are connected to a host USB (PC or USB HUB).

ESP32-S3 WROOM is power by a external source (not USB powered).

Version

Arduino v2.0.14 and v2.0.17

IDE Name

PlatformIO

Operating System

Windows 10

Flash frequency

40 Mhz

PSRAM enabled

yes

Upload speed

115200

Description

I am trying to restart the ESP32-S3 in download mode via a command in the firmware. I am using the internal PHY (pins 19 and 20) for CDC communication using the tinyUSB library through the 'USBCDC' class.

I am executing the following command and experiencing two different behaviors.

usb_persist_restart(RESTART_BOOTLOADER);
  • When the ESP32-S3 is directly connected to my computer's USB port, it fails to restart and gets stuck, eventually sending a timeout message.
  • When the ESP32-S3 is connected to a USB hub, it restarts correctly and enters download mode.

Sketch

#include <Arduino.h>

void setup()
{
    // A API do USB CDC deve ser iniciado antes do USB
  USBCDC USBSerial;
  // Instância as características do USB
  USB.VID(0x303a);
  USB.PID(0x303a);
  USB.usbClass(0x02);
  USB.usbSubClass(0x02);
  USB.usbProtocol(0x00);
  USB.begin();

  delay(2000);
  usb_persist_restart(RESTART_BOOTLOADER);
}

void loop()
{  
  while(true)
  {
    delay(1000);
  }
}

Debug Message

When the ESP32-S3 is connect diretly to the PC it shows theses menssages:

- [  9625][E][esp32-hal-tinyusb.c:452] usb_switch_to_cdc_jtag(): reset_sem timeout

This problem occurs on esp32-hal-tinyusb.c on usb_switch_to_cdc_jtag method. For some reason it don't get into this method esp_intr_alloc(ETS_USB_SERIAL_JTAG_INTR_SOURCE, 0, hw_cdc_reset_handler, reset_sem, &intr_handle).

17:24:08.131 -> ESP-ROM:esp32s3-20210327
17:24:08.166 -> Build:Mar 27 2021
17:24:08.166 -> rst:0x1 (POWERON),boot:0x8 (SPI_FAST_FLASH_BOOT)
17:24:08.166 -> SPIWP:0xee
17:24:08.166 -> mode:DIO, clock div:1
17:24:08.166 -> load:0x3fce3808,len:0x44c
17:24:08.166 -> load:0x403c9700,len:0xbd8
17:24:08.166 -> load:0x403cc700,len:0x2a80
17:24:08.166 -> entry 0x403c98d0
17:24:11.245 -> �������ESP-ROM:esp32s3-20210327
17:24:11.245 -> Build:Mar 27 2021
17:24:11.281 -> rst:0xc (RTC_SW_CPU_RST),boot:0x0 (DOWNLOAD(USB/UART0))
17:24:11.281 -> Saved PC:0x4202c4f2
17:24:11.281 -> waiting for download
17:24:11.390 -> Guru Meditation Error: Core 0 panic'ed (LoadProhibited)
17:24:11.390 -> Core 0 register dump:
17:24:11.390 -> PC      : 0x400511b1  PS      : 0x00060330  A0      : 0x80049188  A1      : 0x3fceb640
17:24:11.390 -> A2      : 0x00000000  A3      : 0x3ff1e3fb  A4      : 0x00000001  A5      : 0x00000000
17:24:11.390 -> A6      : 0x00000000  A7      : 0x00000088  A8      : 0x800533dc  A9      : 0x3fceb620
17:24:11.390 -> A10     : 0xfffffffb  A11     : 0x3fceeebc  A12     : 0x3fceefbc  A13     : 0x00000000
17:24:11.390 -> A14     : 0x00000000  A15     : 0x00000006  SAR     : 0x0000000f  EXCCAUSE: 0x0000001c
17:24:11.390 -> EXCVADDR: 0x00000000  LBEG    : 0x400570e8  LEND    : 0x400570f3  LCOUNT  : 0x00000000
17:24:11.390 -> 
17:24:11.390 -> Backtrace: 0x400511b1:0x3fceb640 0x40049185:0x3fceb670 0x400491e5:0x3fceb690 0x40043917:0x3fceb6b0 0x4004392a:0x3fceb6d0 0x40043c33:0x3fceb6f0 0x40034c45:0x3fceb710
17:24:11.390 ->

Other Steps to Reproduce

To reproduce this issue you will need a USB HUB.

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

  • I confirm I have checked existing issues, online documentation and Troubleshooting guide.
@rafaelgerges rafaelgerges added the Status: Awaiting triage Issue is waiting for triage label Aug 19, 2024
@me-no-dev
Copy link
Member

usb_persist_restart() is not to be used directly. Also persist does not work on S3 at all

@rafaelgerges
Copy link
Author

Well, if it shouldn't be accessed directly then it should be a private method, that would be an improvement. And, if it doesn't work on all ESP32-S3s, would that be a bug? What would be the correct way to put the ESP32-S3 in download mode via software?

@Jason2866
Copy link
Collaborator

put the ESP32-S3 in download mode via software?

Short answer. There is no software solution for bringing the S3 in download mode.

@atanisoft
Copy link
Collaborator

Using REG_WRITE(RTC_CNTL_OPTION1_REG, RTC_CNTL_FORCE_DOWNLOAD_BOOT); and forcing a reboot seems to work on the ESP32-S3 from my tests. But it's a bit problematic from TinyUSB usage.

@rafaelgerges
Copy link
Author

put the ESP32-S3 in download mode via software?

Short answer. There is no software solution for bringing the S3 in download mode.

What would you suggest as a hardware solution? Perhaps using a LATCH circuit connected to the BOOT pin?

@rafaelgerges
Copy link
Author

Using REG_WRITE(RTC_CNTL_OPTION1_REG, RTC_CNTL_FORCE_DOWNLOAD_BOOT); and forcing a reboot seems to work on the ESP32-S3 from my tests. But it's a bit problematic from TinyUSB usage.

I tried this solution, unfortunately it didn't work for my case, maybe due to TinyUSB as you commented.

@atanisoft
Copy link
Collaborator

That's unfortunate. For my use case (TinyUSB operating a CDC endpoint) I jumped through a number of hoops to get the download mode working and it's far from ideal since esptool.py requires two invocations (first triggers the download mode but times out waiting for the device readiness, second does the actual download). I'm investigating further how to avoid the double execution of esptool but it's a lower priority since it is working right now.

Make sure you fully deinitialize the TinyUSB stack before you trigger the reboot.

@rafaelgerges
Copy link
Author

That's unfortunate. For my use case (TinyUSB operating a CDC endpoint) I jumped through a number of hoops to get the download mode working and it's far from ideal since esptool.py requires two invocations (first triggers the download mode but times out waiting for the device readiness, second does the actual download). I'm investigating further how to avoid the double execution of esptool but it's a lower priority since it is working right now.

Make sure you fully deinitialize the TinyUSB stack before you trigger the reboot.

Thanks, any suggestion on how to fully deinitialize TinyUSB?

@me-no-dev
Copy link
Member

if usb_persist_restart(RESTART_BOOTLOADER); does not work, this was our best bet. We have had this issue since S3 was released and were not able to make it work fully ever.

@SuGlider SuGlider added Type: Question Only question and removed Status: Awaiting triage Issue is waiting for triage labels Aug 22, 2024
@rafaelgerges
Copy link
Author

if usb_persist_restart(RESTART_BOOTLOADER); does not work, this was our best bet. We have had this issue since S3 was released and were not able to make it work fully ever.

But somehow it worked, as I mentioned earlier, when ESP32-S3 is connected to a USB HUB, this method works perfectly but when ESP32-S3 is connected directly to the PC's USB port it really doesn't work.

@me-no-dev
Copy link
Member

you said that it gave exception. Any chance you decode that backtrace with the ESP Exception Decoder?

@rafaelgerges
Copy link
Author

you said that it gave exception. Any chance you decode that backtrace with the ESP Exception Decoder?

Sure, give me a couple o days and I will send you back.

@rafaelgerges
Copy link
Author

@me-no-dev sorry about the delay, I will probably do that on this week. Just wait a little bit more.

@rafaelgerges
Copy link
Author

you said that it gave exception. Any chance you decode that backtrace with the ESP Exception Decoder?

Ok, below is the code with the backtrace and the decoder, unfortunately it was not able to provide very clear information about what happens. I run it on PlatformIO with build_flag = debug and monitor_filters = esp32_exception_decoder

Build:Mar 27 2021
rst:0xc (RTC_SW_CPU_RST),boot:0x0 (DOWNLOAD(USB/UART0))
Saved PC:0x42046152
waiting for download
Guru Meditation Error: Core 0 panic'ed (LoadProhibited)
Core 0 register dump:
PC      : 0x400511b1  PS      : 0x00060330  A0      : 0x80049188  A1      : 0x3fceb640
A2      : 0x00000000  A3      : 0x3ff1e3fb  A4      : 0x00000001  A5      : 0x00000000
A6      : 0x00000000  A7      : 0x00000088  A8      : 0x800533dc  A9      : 0x3fceb620
A10     : 0xfffffffb  A11     : 0x3fceeebc  A12     : 0x3fceefbc  A13     : 0x00000000
A14     : 0x00000000  A15     : 0x00000006  SAR     : 0x0000000f  EXCCAUSE: 0x0000001c
EXCVADDR: 0x00000000  LBEG    : 0x400570e8  LEND    : 0x400570f3  LCOUNT  : 0x00000000

Backtrace: 0x400511b1:0x3fceb640 0x40049185:0x3fceb670 0x400491e5:0x3fceb690 0x40043917:0x3fceb6b0 0x4004392a:0x3fceb6d0 0x40043c33:0x3fceb6f0 0x40034c45:0x3fceb710

  #0  0x400511b1:0x3fceb640 in ?? ??:0
  #1  0x40049185:0x3fceb670 in ?? ??:0
  #2  0x400491e5:0x3fceb690 in ?? ??:0
  #3  0x40043917:0x3fceb6b0 in ?? ??:0
  #4  0x4004392a:0x3fceb6d0 in ?? ??:0
  #5  0x40043c33:0x3fceb6f0 in ?? ??:0
  #6  0x40034c45:0x3fceb710 in ?? ??:0

Any clue or suggestion?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Question Only question
Projects
None yet
Development

No branches or pull requests

5 participants