programming + reset issue with CDC/USB-JTAG on ESP32C3

[0x0fe]

Board

ESP32C3 custom board

Device Description

Custom ESP32C3 board ;
The ESP32C3 is only connected to USB-C port, two 74HCT245D buffers (inputs only) and a tact switch (details below).
This ESP32C3 design block, which follows the hardware design guide, has already been used in several boards and products without issue, there is however always differences between the designs on the pullup/pulldowns presents on the various GPIOs, nontheless all designs have pullup on 2 and 8 boot strap pins, this one is no exception.

Hardware Configuration

PIN MAP:

• 2, 3, 4, 5, 6, 7, 8, 10, 20, 21 to 74HCT245 inputs
• 9 to tact switch (no external pullup)
• 10K pullups on 2, 8 and 20
• RC reset on EN (10K pullup + 1uF to GND)

High quality 3.3V LDO with very low drop at max load and high PSRR.
Sufficient decoupling all over (100nF 50V X7R class),
Sufficient storage capacitors on the 3.3V rail with large derating (2*22uF 16V).
Ferrite bead on 5V rail plus 3.3V rail filtering as per hardware design reference.

Version

v2.0.4

IDE Name

Arduino

Operating System

windows 10

Flash frequency

80M

PSRAM enabled

no

Upload speed

921600 (not relevant for CDC)

Description

• when plugged to USB, the board runs normally and the USB port is recognized normally
• when trying to program, the CDC does not manage to reset the board in programming mode, i get the follwing error

Connecting......................................
A fatal error occurred: Failed to connect to ESP32-C3: Wrong boot mode detected (0xc)! The chip needs to be in download mode.

The only way to program is to unplug, hold the tact switch (gpio9) plug USB and release tact to force PROG mode
the programming then executes normally, however it does not manage to reset and run afterwards, a manual power cycle has to be executed.

Is there another bootstrap pin causing the issue? (other than 2 and 8 which are already pulled high)
is it something with the RC reset?
It is unclear to me how only the CDC reset fails but when i cold boot (aka plug USB) the board starts in the correct RUN mode, and when i use GPIO9 it starts in the correct PROG mode.

Note :

• the board does resets briefly a few time during programming attemps, so the CDC tries to reset, but fails to set the PROG mode.
• the issue is not related to the firmware itself, as the error can be reproduced with a test firmware doing nothing else than running printf + delay in the main loop.

Sketch

void setup() {
  Serial.begin(115200);
  while(!Serial) delay(1);
  printf("init\n");
}
void loop() {
  printf("test\n"); 
  delay(500);
}

### Debug Message

```plain
Connecting......................................
A fatal error occurred: Failed to connect to ESP32-C3: Wrong boot mode detected (0xc)! The chip needs to be in download mode.

### Other Steps to Reproduce

HW setup with two buffer and pullups as described will reproduce the issue

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

- [X] I confirm I have checked existing issues, online documentation and Troubleshooting guide.

[SuGlider]

The ESP32-C3-DEVKITC-1 schematics has the CP2102 DTR/RTS and connection to GPIO 9 (Boot).
The USB Serial/JTAG Controller is able to put the ESP32-C3 into download mode automatically. Simply flash as usual, but specify the USB Serial/JTAG Controller port on your system: idf.py flash -p PORT where PORT is the name of the proper port.

https://docs.espressif.com/projects/esp-idf/en/latest/esp32c3/api-guides/usb-serial-jtag-console.html
https://docs.espressif.com/projects/esptool/en/latest/esp32c3/advanced-topics/boot-mode-selection.html

[SuGlider]

GPIO2, GPIO8, and GPIO9 are strapping pins of the ESP32-C3FN4 chip. These pins are used to control several chip functions depending on binary voltage values applied to the pins during chip power-up or system reset. For description and application of the strapping pins, please refer to Section Strapping Pins in ESP32-C3 Datasheet.

[0x0fe]

i am sorry but your two answers are quite out of touch, maybe you should read the issue again, No one asked the principle of using internal JTAG to flash, nor what bootstrap pins are, it is rather obvious that i already know since i designed the board to use native USB for programming and i mention several times the boot strap pins pullup configuration. That doesnt help a bit with the problem.

[0x0fe]

also, i use the C3F4H variant (but this changes nothing to the problem).

[SuGlider]

I'm sorry for not been of help.
We deal with software here in this GitHub, not hardware.

What is the software issue, related to the ESP32 Arduino Core implementation, that you have?

[SuGlider]

CDC software layer must be loaded prior to being able to use it.

Thus, first upload any sketch using CDC enabled option from Arduino IDE in order to, in the next board reset, have CDC working and make it understand USB signaling for software upload and board reset.

Not sure if this has been already tried.

[Jason2866]

@SuGlider We do it this way for Tasmota and devices which "just" uses the CDC.
Or to be more correct the USB/JTAG mode. Works like a charm. First time only needed to put manually in flash mode next time it does work like it has hardware reset circuitery.
@0x0fe Take a look in Tasmota source code how it can be done ;-)

[0x0fe]

@SuGlider
the CDC is obviously enabled and used, you could have guessed it by the test sketch i gave and the fact i precised the board uses only native USB. I also precised that the "CDC reset" is working : I have confirmed the C3 does reset a few times, still it never manages to get into PROG mode.
I implemented that CDC reset mechanism on other MCUs years ago so i have a pretty good idea on how it works.
The problem here is not the CDC reset, its the setting to PROG mode, it stay stuck into RUN mode (0xc).
I havent looked into the details on how it is implemented here, but usually we write on a register / flash so that after the reset the bootloader goes into PROG mode, i assume it is done in a similar way here except with internal jtag and thus i have a very hard time understanding how the hardware could possibbly have any impact on this. But it does since the programming is failing on this specifc design.
On other design it works fine and i use it everyday, also that is the 7th production design with this ESP32C3 block so its not like we are starting with it.

@Jason2866
Not sure what you are talking about, CDC and internal JTAG are two different things, the CDC is used to reset into prog mode then the internal jtag block takes over for the reprogramming phase. Using CDC to trigger a reset is an old trick. This mechanism is already implemented in the arduino core and works fine, So, yes, that is how it works, what does it have to do with the issue?

The problem is that, on this particular board, this programming via CDC/JTAG just fails and it shouldnt. Something is preventing it to work correctly. As I shown in the log, the C3 is still stuck in RUN mode after being reset by the CDC, that is the issue.

Also, if we force PROG by booting with GPIO 9 low (and releasing it after power up) then the C3 become stuck in PROG mode, we can program it over and over but it never resets to RUN mode by itself, only a power cycle does. Which is also totally abnormal.

[SuGlider]

@0x0fe - where do you think the problem is?

[SuGlider]

Last 2 cents:

JTAG/CDC USB interface uses DTR/RTS bits to reset and enter in Boot Mode.

The way it works can change depending on the eFuses.

Maybe you may want to check it.

This information is in page 612 it the C3 TRM and eFuse is explained in the chapter 4 of the TRM.

Maybe the eFuses of your chip are wrong.