ESP32-C3 can't leave Download Mode

[bssmr32]

Dear All,

I'm tasked with programming a whole bunch of custom ESP32-C3-MINI-1 boards. The board is equipped with a push-button on GPIO9. When pressed GPIO9 is pulled to GND.

The procedure goes as follows:

The push-button is held pressed, then the board is connected via its USB connector receiving power. Now the push button is released. The USBs data lines are connected to the USB-JTAG-Serial interface for the ESP32-C3.
The ESP is now in Download Mode, as GPIO9 was LOW during power-on. Now I'm using the esptool.py to program my firmware image.

The next step is causing me some headache. I need the freshly programmed code to run on the ESP in order to do some QA checks. After the reset by the esptool (--after hard_reset) the ESP starts again in Download Mode which is obviously not what I want.


The Technical Referance manual states in Section 7.1:

During power-on reset, RTC watchdog reset, brownout reset, analog super watchdog reset, and crystal clock
glitch detection reset (see Chapter 6 Reset and Clock), 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 GPIO_STRAPPING.

So it becomes clear, that the reset executed by the esptool does not cause the strapping PINs to be re-evaluated. Power-cycling the board works but is not an option, as it would require a manual intervention.


Now I tried the following which does not work as expected:

I uploaded a tiny program into RAM (esptool.py load_ram) that causes a RTC watchdog reset which should cause the strapping PINs to be re-evaluated und thus allow the ESP to start into SPI Boot Mode.



Here is the output of the USB-CDC UART after uploading mit in-RAM code:

Code: Select all

............................................ESP-ROM:esp32c3-api1-20210207
Build:Feb  7 2021
rst:0x9 (RTCWDT_SYS_RST),boot:0x5 (DOWNLOAD(USB/UART0/1))
Saved PC:0x4004c0d4
waiting for download

My code prints dots (.) in a loop while waiting for the RTC WDT to cause a system reset. Now, the reset reason confirms, that the WDT worked as intended. But why is the strapping PINs still at 0x5? It really should be 0xd (SPI Flash Boot).

If I power-cycle the ESP that it stats in Flash Boot (BOOT:0xd), so the level of GPIO9 is not the issue.

Thanks for reading all this and thanks for your help.


tl;dr:
Why are GPIO_STRAPPING stuck at the power-on values even after a RTCWDT_SYS_RST? Manual says rtc watchdog reset causes the strapping PINs to be read on RTCWDT_SYS_RST.

[MicroController]

Not sure what the underlying problem is, but

The USBs data lines are connected to the USB-JTAG-Serial interface for the ESP32-C3.
The ESP is now in Download Mode, as GPIO9 was LOW during power-on. Now I'm using the esptool.py to program my firmware image.

esptool.py should be able to automatically reset the chip and enter download mode prior to flashing via the USB-JTAG-Serial, without any button pressing or power-cycling.

[ESP_Sprite]

esptool.py should be able to automatically reset the chip and enter download mode prior to flashing via the USB-JTAG-Serial, without any button pressing or power-cycling.

No, that's actually correct: if you lower GPIO9 to go to download mode, the USB-serial-JTAG device by itself can't get out of that.

OP: Sorry, no idea why that does that. I'll ask, possibly the datasheet is wrong.

[bssmr32]

Thank you for your replies. A factory-new ESP32-C3 can in fact only be put in download mode pulling GPIO9 to GND. That is, using the built-in USB-SERIAL-JTAG. One could add additional hardware such as USB-UART-Bridge allowing to pull GPIO9 to GND using serial control lines. But what's the point of that having a perfectly working built-in USB.

@ESP_Sprite
I'm curious what you'll find out. Both the Technical Reference Manual and the Datasheet state, that - amongst others - a RTC WDT Reset would do the trick.

[MicroController]

@Sprite: I meant to hint that, since USB-JTAG is connected, OP wouldn't even need to manually pull GPIO9 low as part of his programming procedure in the first place, and could thus avoid the described issue.

A factory-new ESP32-C3 can in fact only be put in download mode pulling GPIO9 to GND. That is, using the built-in USB-SERIAL-JTAG.

Huh? I don't understand. Are you saying the C3 can only or cannot be put in download mode via USB-Serial-JTAG?
Why would a "factory-new" C3 behave any different in that regard than any other C3? (except after permanently disabling USB-JTAG via e-fuse)

[bssmr32]

I mean, that i cannot put a factory new ESP32-C3 into download mode using USB-SERIAL-JTAG and esptool alone. This only works after I flashed the firmware once (using GPIO9). I tried it several times and accepted it as a given thing. I thought maybe it needed the 2nd stage bootloader that comes with the ESP-IDF Project which is not present on an empty flash memory.

[ESP_Sprite]

The story there is that an ESP32-C3 with empty flash will try to boot from that flash continuously but also has a RTC watchdog running. The idea is that if the chip ends up in a situation with valid flash but something in the chip prevents it from booting from that, the RTC watchdog will reset the chip after a bunch of attempts. Unfortunately, the RTC WDT also resets the USB-serial-JTAG device making it tricky to get a proper connection to it, depending on how fast your OS is in establishing an USB connection. (When esptool.py is connected, it'll disable that WDT and there is no issue anymore). However, in download mode forced by lowering GPIO9, the WDT does not run and you can get a connection all the time.

[MicroController]

Thanks for clearing that up for me