ESP32-C3 Stuck waiting for download

[ashesman]

Hi,

Custom PCB with ESP32-C3-MINI module. Using the ESP32s onboard USB. On one PCB when I run idf.py monitor, it sometimes gets stuck at waiting for download (see below). I have confirmed that IO9 is kept high. Other PCBs do not have this problem. Any suggestions on what could be the cause?

This problem never happens the first time after the ESP32 is power cycled. It also sometimes doesn't happen at all and I can start/stop the monitor as many times as I want. Once it gets stuck in this state, it doesn't matter how many times I restart monitor, it is always waiting for download. A power cycle is required.

The flash memory is OK and programmed. When it is stuck, a power cycle always boots OK.

Code: Select all

>idf.py -p COM10 monitor
Executing action: monitor
Running idf_monitor in directory c:\users\ashley\documents\esp32\evnexhomeesp32firmware
Executing "C:\Espressif\python_env\idf4.4_py3.8_env\Scripts\python.exe C:\Espressif\frameworks\esp-idf-v4.4.2\tools/idf_monitor.py -p COM10 -b 115200 --toolchain-prefix riscv32-esp-elf- --target esp32c3 --decode-panic backtrace c:\users\ashley\documents\esp32\evnexhomeesp32firmware\build\EvnexHomeESP32Firmware.elf -m 'C:\Espressif\python_env\idf4.4_py3.8_env\Scripts\python.exe' 'C:\Espressif\frameworks\esp-idf-v4.4.2\tools\idf.py' '-p' 'COM10'"...
←[0;33m--- WARNING: GDB cannot open serial ports accessed as COMx←[0m
←[0;33m--- Using \\.\COM10 instead...←[0m
←[0;33m--- idf_monitor on \\.\COM10 115200 ---←[0m
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
ESP-ROM:esp32c3-api1-20210207
Build:Feb  7 2021
rst:0x15 (USB_UART_CHIP_RESET),boot:0x5 (DOWNLOAD(USB/UART0/1))
Saved PC:0x400462e2
waiting for download

I have noticed that when it is OK, if I start the monitor, the reset flags are as below. For some reason when it gets stuck the DOWNLOAD flag is set!

Code: Select all

rst:0x15 (USB_UART_CHIP_RESET),boot:0xd (SPI_FAST_FLASH_BOOT)

[ESP_Sprite]

It means that on startup, GPIO9 was low; when the ESP32C3 is put in download mode that way, it needs a hard (external) reset with GPIO9 high to get out of that. Do you have anything specific connected to GPIO9? Do you have the required RC network on the EN pad of the module?

[ashesman]

Thanks for your reply. GPIO9 is controlled by an external microcontroller. I have confirmed GPIO9 always stays high on a scope. Enable is also controlled by an external microcontroller. It does have a pullup and capacitor fitted but for these tests, EN is bridged directly to 3V3 by a jumper wire.

That is why this problem is confusing, The pins do not change state. Also this problem seems to be intermittent on one PCB only. I suspect maybe e a soldering problem, but even then, GPIO9 is pulled up internally, so even if the pin is not soldered it still should not go into boot loader mode!

[ESP_Sprite]

That's no good, EN absolutely needs that RC network to provide a good power-on reset. Also note that the IO9 signal is sampled just after reset goes high; the level when the ESP is already booted is not relevant. In other words: if this happens on power-up and the microcontroller doesn't raise GPIO9 before EN of the ESP goes high, you will see this.

[ashesman]

Maybe I did not explain well. This does not happen at power up at all. For example yesterday I debugged code all day. Started and stopped the monitor about 50 times probably. After about four hours, one time when I restarted the monitor, it was stuck waiting for download. It didn't matter how many times I restarted the monitor, it was stuck. I cycled the power to the part and everything was good again for the rest of the day.

The EN and IO9 pins cannot change state, they are both driven hard to 3V3 at the moment. Also, other PCBs I have with exactly the same setup do not have this problem, just one.

I would like to understand what is going on so I can be sure it is not a design issue and it is just luck I haven't seen it on other parts yet.

[ESP_Sprite]

Again, EN connected hard to 3.3V is not something that is in spec: unless you give the ESP32C3 a good power-on reset via e.g. a RC-network on EN, unexpected things can happen (because some parts of the chip may be in latchup, for example). Not saying that that this is absolutely the cause for this behaviour, but it could be. Note that a reset via the USB-JTAG-serial converter is not a good replacement as it doesn't reset in the same way the EN input does.

What happens if you reset the chip using ctrl-T ctrl-R in the monitor? Does it still go into download mode?

[ashesman]

Probably worth mentioning that enable never changes state during this process. I can debug for four hours, resetting, flashing, monitor... I never turn power off, or never change the state of EN. Then all of a sudden after flashing it will refuse to start. Stuck in download mode. I still have this issue, but it is really hard to reproduce. I cant make it happen, just does it when it feels like!

In production, these boards have the capacitor on enable and are powered up, then EN released by the host MCU. It is just for development I have tied EN high to stop the hist resetting the ESP32 during flashing etc.

IO9 is pulled high both internally and externally, so I don't see how it could be held low momentarily during a reset.

Once the ESP32 is in this state, it needs to be powered off for some time to come right. Quickly dropping 3V3 doesn't help. Only a good 10 seconds without power.

[Alberk]

Is it possible to replace the ESP32-C3 on the problem board, just to eliminate the problem with MCU.

[ashesman]

Ideally I would rather not replace it. It is a ESP32-C3-MINI module so impossible to replace reliably without specialist tooling.