ESP32 Forum

Hello.

I'm using ESP32-C3-DevKitC-02 development board with ESP32-C3 (rev. 0.3) with ESP-IDF Stable v 5.0.1 (all operations are performed in ESP-IDF Windows Command Prompt).

I want to flash the example blinky project using built-in JTAG capabilities. To do that I made a custom USB-cable and connected its header to the DevKit board as follows:

GPIO18 -> USB_D-
GPIO19 -> USB_D+
G -> GND

The other end of the cable is a USB-A flat connector, which is connected to the PC with Windows 10.

A new COM-port (later referred as COM-JTAG) is discovered in Windows' Device Manager and appears everytime I connect the header to DevKit board.
When I press and hold RST button, the COM-JTAG port disappears and re-appears when the RST button is released. I assume this is a normal behaviour.

Now, in order to flash (according to https://docs.espressif.com/projects/esp ... nsole.html):

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.

So I typed in the command:
which hangs for several seconds on the line 'Serial port COM37' and then returns an error "A serial exception error occurred: Write timeout".

At the same time I still can flash the device with the UART0 COM-port.

Then I entered the boot mode (held Boot button and pressed RST button) and this time command
worked and device was programmed successfully. The last message that appeared after flashing was:

Leaving...
Hard resetting via RTS pin...
Done

However device didn't reset and I assume stayed in the bootloader. Only pressing the RST button would reset the device into the user app.
Once in the user app, flashing using COM-JTAG wouldn't work again.

Documentation specifically states that the USB Serial/JTAG Controller is able to put the ESP32-C3 into download mode automatically (without UART's RTS/DTS signals), which is not what's happening.

It sounds like you're using a really old version of esptool.py which doesn't have support for the USB-jtag-serial adapter (it has a DTR/RTS reset sequence that is a bit different from the one on an UART.) Can you try updating that and try again?

It sounds like you're using a really old version of esptool.py which doesn't have support for the USB-jtag-serial adapter (it has a DTR/RTS reset sequence that is a bit different from the one on an UART.) Can you try updating that and try again?

Thank you for the reply.

I have the latest stable version of ESP-IDF v 5.0.1 and it has esptool.py version v4.5. Isn't it the latest version? If not, how do I update it to the latest version? I installed ESP-IDF using offline installer.

Here's the full log when trying to flash when user app is active (failed):
Here's the full log when trying to flash when bootloader is active (successfull):

Ok, so I updated esptool from 4.5 to the latest release version 4.5.1 and nothing changed.
Then I even updated to the latest master branch (4.6dev0) and still nothing changed. It behaves exactly the same as on version 4.5.

In the example blink program, you didn't happen to change the GPIO pin it controls the LED by to GPIO18/GPIO19? You can check that in menuconfig, under 'example configuration'. Also, you didn't add any code that otherwise controls/reconfigures those pins?

In the example blink program, you didn't happen to change the GPIO pin it controls the LED by to GPIO18/GPIO19? You can check that in menuconfig, under 'example configuration'. Also, you didn't add any code that otherwise controls/reconfigures those pins?

No, nothing is changed. I also tried flashing a project which is a carbon copy of the ' hello_world' example project and it also doesn't work.

I noticed that when the 'flash' command is issued, the board is actually reset (on UART0-TX pin there's a default boot log), but is not entering the boot mode. CHIP_EN and GPIO9 pins are not controlled by anything in this mode, so a software reset must be happening, and I assume that the boot enter conditions are not met. I don't know how and when these conditions are supposed to be set in the software, but it's just not happening.

When the cable is connected and no flash operation is in progress, here are the waveforms on D+ (yellow) and D- (blue) lines:
These waveforms are the same in user app mode and in boot mode. As you can see, USB packets are sent every 1 ms.

When 'flash' command is issued, the data is sent on a high frequency, and difference between user and boot mode is that in boot mode the process actually moves on forward and eventually ends, while in user mode it seems stuck, probably meaning that there's no answer for a command (no answer, because program on pc thinks that after reboot device is in boot mode, but in reality it is in the user app).

Yes, those 1ms packets are SOF packets; they're 'background chatter' of USB. I'm afraid that with only a scope (no USB protocol analyzer) you're not gonna get far debugging this.

What I think is happening is that somehow, esptool fails to detect that this is an USB-serial-JTAG port and doesn't apply the correct reset sequence. I'll check with my colleagues if there's some way to force this.

By the way, VSCode plugin flashes using OpenOCD and it works (no bootloader required for that?).

In the terminal you could also write manually:
But it's not convenient to type all of these commands one by one every time.

Could you see what happens when you manually run esptool forcing it to use the USB-JTAG-serial dance? Something like (Specifically, the --before=usb_reset is the important bit)