ESP32 Forum

Hello,
I have recently designed a custom board using the ESP32-C3 and have a micro-usb port that I am using to power and program the board. Everything is going well; however, I seem to have trouble putting the board into Download mode via the usb. I can see the COM port show up in Device Manager on windows so I know it is being recognized and see it disappear and reappear as per ussual. I can use idf.py monitor to see the invalid header messages. When I attempt to flash i keep on getting

A device which does not exist was specified.

To get around this, I manually force GPIO9 LOW to put it into download mode, and then the flash goes through normally. I am using release/4.4 of the esp-idf. Am I missing something? Thank you.

Do you happen to use WiFi or BT in your program? If so, you might have run into a known bug. The workaround for it is to select USB serial/JTAG as the primary console output: you can do that in menuconfig → Component config → ESP System Settings → Channel for console output.

I do use WIFI. This bug would still have an effect even when there is nothing installed and it is a totally fresh ESP32-C3?

As in: nothing in the flash, brand new, entirely empty? The issue then could be that the RTC watchdog resets the ESP every few seconds or so, making the USB interface re-enumerate. That can make it a bit hard to connect to the chip to get into download mode (as in: you need to have the luck that the chip doesn't happen to reset when it gets put in download mode) but in our experience after a try or two it still flashes.

Yes, the chip is entirely empty and is fresh off the reel. I did notice the Watchdog was resetting the chip every few seconds. I probably tried ~100 times before I gave up and just forced it as described above. Could there be any interaction with some of the pins either left floating or forced either HIGH/LOW that could be causing this odd interaction? Or the BAUD rate being at a too high of rate?

dgduncan wrote: ↑

Wed Feb 23, 2022 9:49 pm

Could there be any interaction with some of the pins either left floating or forced either HIGH/LOW that could be causing this odd interaction?

Not really, I don't think USB-serial-JTAG is affected by any GPIO by default.

Or the BAUD rate being at a too high of rate?

Certainly not. The baudrate in this case is a fiction as there's no actual physical serial stream involved. The USB-serial-JTAG device accepts requests to change/set the baudrate, but entirely ignores it afterwards. You could set the baudrate to 110 baud and uploading would still be fast.


Honestly, given the fact that you can flash the chip if GPIO9 is pulled low, I think the reset behaviour is at fault here. Can you post a bit more information about your setup: hardware used, USB hub, operating system used, are you flashing from a VM, etc?

My setup is Windows 10. USB directly hooked up to the motherboard. ESP-IDF version release/4.4. Module used is ESP32-C3-WROOM-02-H4.

For shits and giggles, could you see what happens if you put an USB hub in between? We've seen at least one instance where that fixed weirdness.

I will try that and check back

hi,
I’m currently experiencing the same issue.
I can't upload firmware to esp32-c3 super mini

pload_port = \\.\COM4 <-- Com Ports" in Device Manager in Windows 10 when in DFU mode

;upload_speed = 2000000
upload_speed = 115200
monitor_speed = 115200

Thanks in advance for any help you may have,

Chip is ESP32-C3 (revision v0.4)
Features: WiFi, BLE
Crystal is 40MHz
MAC: dc:da:0c:8e:ba:e0
Uploading stub...
Running stub...
Stub running...
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 0x000fafff...
Compressed 13216 bytes to 9529...

A fatal error occurred: Packet content transfer stopped (received 8 bytes)
*** [upload] Error 2