Can't reboot device using USB Serial JTAG when in DOWNLOAD_MODE (ESPTOOL-842) #970
Comments
github-actions
bot
changed the title
|
I've also tried rebooting using the |
|
when my device gets in this "stuck" state, i've tried invoking everytime I call the command it says it "succeeds". but my device does not actually reboot. it appears to do nothing. only physically pulling the power cord will reboot it. |
|
Hi @chipweinberger. Of course it reports success. There is no confirmation or check that the reset have been successful. The appropriate pin has been toggled using RTS of the serial interface. But there is no actual confirmation that the chip has been reseted. I'm afraid you made a mistake in the PCB design and that is why the chip cannot be reseted automatically. |
|
Thanks for the response, but I don't understand. In theory could have an ESP32 with only 4 pins connected:
Is this sufficient for USB Serial JTAG to reset the chip? What other PCB traces / design would you need? |
|
I just tried using |
|
@igrr curious your thoughts here as well. |
|
I've found the underlying cause. when my device is in this "stuck" state, refusing to reboot, running This is the cause! Straight from the espressif factory, I always have to put my esp32s3 into DOWNLOAD MODE using GPIO 0. This is the only way I know to get an esp32s3 straight from the factory to listen over usb serial jtag. If I do not first put my device into DOWNLOAD MODE, then my reboot command works. This is tricky though, because I need DOWNLOAD MODE to program my device. Yet, it prevents rebooting into the application without physically pulling the power cord. I really don't want to have to physically the power cord during my manufacturing process. Is there any way to program an esp32s3 then reboot into my application using USB Serial JTAG, programmatically? |
|
Hi @chipweinberger,
Yes, the USB-Serial/JTAG peripheral has a state machine that detects the
That means you manually put the device into download mode by physically pulling the GPIO0 strapping pin down. During bootup, this gets stored in the strapping pin register. If that isn't cleared, USB-Serial/JTAG might not be able to leave the download mode., You can try updating esptool to the latest master, we have recently added clearing of the boot control register during reset: 1c355f9 |
|
@radimkarnis , that looks like exactly the issue I am having. yay. I'm very close to production at this point, so I don't want to switch to master. I guess I could cherry-pick this commit. let me try that. |
|
@radimkarnis , I'm currently on v5.1, and can't seem to find that file Edit: found it here /Volumes/User/MBP-Google-Drive/jamcorder/firmware/.espressif/python_env/idf5.1_py3.9_env/lib/python3.9/site-packages/esptool/targets/esp32s3.py Would you be able to give me a little guidance? / how long would I need to wait for this to hit v5.1? |
|
Ok, sorry. I've missed that you are using USB Serial JTAG. |
|
Esptool installed in the ESP-IDF environment. After activating the environment, you can upgrade it by running
I don't have an exact estimate. esptool 4.8 will be probably released in 3-6 Months. |
|
I've tried patching in the change, but it still does not reboot my device! Logs confirm my patch is being called. idf.py monitor is still in download mode |
|
I have tried to reproduce this and can confirm this happens. If download mode is entered by pulling the BOOT strapping pin low (GPIO0 on ESP32-S3), USB-Serial/JTAG cannot exit the download mode. I am not sure if this is expected behavior. We will look into this and see if this can be patched. |
|
please let me know as soon as you know! thanks until then i've begrudgingly added a physical replug step to my manufacturing line. |
|
a solution it would be ideal if espressif chips listened to serial jtag from the factory without needing download mode that would save me another manufacture step. what firmware do they ship with? why don't they listen? |
And I think we cannot do anything about this. The linked patch turns off the possibility to force of entering download mode by means of a register. If we turn this off then the content of the strapping register (including the captured GPIO0) applies. The strapping register is read only so we cannot do anything about the fact that the chip was put into download mode through GPIO0. We would need a similar "Force normal boot mode" register but there isn't any. I'm sorry, I could not find anything, therefore, I'm afraid that this is not possible.
I think all flash chips are erased and there is no firmware. To the best of my knowledge, the reason is that erasing the flash before flashing takes considerable time and this would delay the production line. To me, flashing through UART in production even thought the application will be using Serial JTAG or OTG sounds the most reasonable solution. |
|
thanks for looking. that's too bad 🙁 |
|
During power-on-reset, RTC watchdog reset, brownout reset, analog super watchdog reset, and crystal clock glitch detection reset (Chapter 7 Reset and Clock in the S3 TRM), hardware captures samples and stores the voltage level of strapping pins as strapping bit of “0” or “1” in latches, and holds these bits until the chip is powered down or shut down. Software can read the latch status (strapping value) from the register GPIO_STRAPPING. The issue here might be that the USB-Serial/JTAG peripheral resets the chip (when an RTS transition is detected), but the reset doesn't qualify for a new reading of the strapping pin voltages (so the GPIO0 reading is being held and the chip enters the download mode again). We will think about patching this in esptool to invoke another kind of reset (possibly RTC watchdog reset) - that could qualify for a new voltage reading on the strapping pins. However, this will take some consideration and time. I am leaving this open until then. |
|
thanks for your updated thoughts could I temporarily fix this in esptool myself in the interim? is there some code i could change? |
|
Maybe this works. |
|
@radimkarnis , any progress? I'd love a patch, because I'll be doing production in 1 month. |
|
I don't think we can issue a proper "patch" due to above-mentioned reasons, more like a "hacky" reset approach. Nevertheless, there is no progress on this task. We will take another look and see if we can up the priority. |
|
right - I meant towards using RTC watchdog reset, or similar. Thanks for thinking about it again. Also curious - is something that would get fixed in a new silicon revision? |
chipweinberger
changed the title
|
Hello @chipweinberger, |
|
Thanks. |
Update: summary of issue: if originally booted in DOWNLOAD_MODE, device stays stuck in DOWNLOAD_MODE. rebooting does not clear strapping pins. This only occurs with USJ. not UART.
Operating System
macOS 13.6.3
Esptool Version
esptool.py v4.6.2
Python Version
Python 3.9.6
Chip Description
esp32s3
Device Description
custom pcb
Hardware Configuration
I have a power-on reset circuit on my custom pcb.
Note: RST is connected to a debug header on the PCB. It's irrelevant to this issue / not used by my flash tool
How is Esptool Run
from python using subprocess
Full Esptool Command Line that Was Run
/Volumes/User/MBP-Google-Drive/jamcorder/firmware/.espressif/python_env/idf5.1_py3.9_env/bin/python /Volumes/User/MBP-Google-Drive/jamcorder/firmware/esp-idf/components/esptool_py/esptool/esptool.py --port /dev/cu.usbmodem101 --chip esp32s3 --no-stub --after hard_reset get_security_infoEsptool Output
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Reboot ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ /Volumes/User/MBP-Google-Drive/jamcorder/firmware/.espressif/python_env/idf5.1_py3.9_env/bin/python /Volumes/User/MBP-Google-Drive/jamcorder/firmware/esp-idf/components/esptool_py/esptool/esptool.py --port /dev/cu.usbmodem101 --chip esp32s3 --no-stub --after hard_reset get_security_info esptool.py v4.6.2 Serial port /dev/cu.usbmodem101 Connecting... Chip is ESP32-S3 (revision v0.2) Features: WiFi, BLE Crystal is 40MHz MAC: 48:27:e2:c9:0a:88 Enabling default SPI flash mode... Flags: 0x00000000 (0b0) Flash_Crypt_Cnt: 0x0 Key_Purposes: (0, 0, 0, 0, 0, 0, 12) Chip_ID: 9 Api_Version: 0 Hard resetting via RTS pin... None None ___ _ _ ___ ___ ___ ___ ___ / __| | | |/ __/ __| __/ __/ __| \__ \ |_| | (_| (__| _|\__ \__ \ |___/\___/ \___\___|___|___/___/ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Console ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Waiting on /dev/cu.usbmodem101 found device! Waiting for Console...More Information
I have my own programming tool that then flashes then listens on the serial port. It does these steps:
get_security_info --after hard_resetserial.Serial()&console.open()There are a few problems:
The only way to get it to reboot is to physically unplug the device and plug it in. then I hear the special tune and the serial console works again.
I Have Read the Troubleshooting Guide
The text was updated successfully, but these errors were encountered: