Built-in JTAG is unable to automatically flash on ESP32-C3-DevKitC-02

[blanchehermine]

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:

Code: Select all

idf.py -p COM37 flash

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

Code: Select all

idf.py -p COM37 flash

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.

[ESP_Sprite]

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?

[blanchehermine]

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.

[blanchehermine]

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

Code: [Select all] [Expand/Collapse]

1. e:\ESP\projects\test>idf.py -p COM37 flash
2. Executing action: flash
3. Running ninja in directory e:\esp\projects\test\build
4. Executing "ninja flash"...
5. [1/5] cmd.exe /C "cd /D E:\ESP\projects\test\build\esp-idf\esptool_py && E:\ESP\ESP-IDF\python_env\idf5.0_py3.8_env\Scripts\python.exe E:/ESP/ESP-IDF/frameworks/esp-idf-v5.0.1/components/partition_table/check_sizes.py --offset 0x8000 partition --type app E:/ESP/projects/test/build/partition_table/partition-table.bin E:/ESP/projects/test/build/test.bin"
6. test.bin binary size 0x2c330 bytes. Smallest app partition is 0x100000 bytes. 0xd3cd0 bytes (83%) free.
7. [2/5] Performing build step for 'bootloader'
8. [1/1] cmd.exe /C "cd /D E:\ESP\projects\test\build\bootloader\esp-idf\esptool_py && E:\ESP\ESP-IDF\python_env\idf5.0_py3.8_env\Scripts\python.exe E:/ESP/ESP-IDF/frameworks/esp-idf-v5.0.1/components/partition_table/check_sizes.py --offset 0x8000 bootloader 0x0 E:/ESP/projects/test/build/bootloader/bootloader.bin"
9. Bootloader binary size 0x4ee0 bytes. 0x3120 bytes (38%) free.
10. [2/3] cmd.exe /C "cd /D E:\ESP\ESP-IDF\frameworks\esp-idf-v5.0.1\components\esptool_py && E:\ESP\ESP-IDF\tools\cmake\3.24.0\bin\cmake.exe -D IDF_PATH=E:/ESP/ESP-IDF/frameworks/esp-idf-v5.0.1 -D SERIAL_TOOL=E:/ESP/ESP-IDF/python_env/idf5.0_py3.8_env/Scripts/python.exe;;E:/ESP/ESP-IDF/frameworks/esp-idf-v5.0.1/components/esptool_py/esptool/esptool.py;--chip;esp32c3 -D SERIAL_TOOL_ARGS=--before=default_reset;--after=hard_reset;write_flash;@flash_args -D WORKING_DIRECTORY=E:/ESP/projects/test/build -P E:/ESP/ESP-IDF/frameworks/esp-idf-v5.0.1/components/esptool_py/run_serial_tool.cmake"
11. esptool esp32c3 -p COM37 -b 460800 --before=default_reset --after=hard_reset write_flash --flash_mode dio --flash_freq 80m --flash_size 4MB 0x0 bootloader/bootloader.bin 0x10000 test.bin 0x8000 partition_table/partition-table.bin
12. esptool.py v4.5
13. Serial port COM37
14. Connecting....
15.  
16. A serial exception error occurred: Write timeout
17. Note: This error originates from pySerial. It is likely not a problem with esptool, but with the hardware connection or drivers.
18. For troubleshooting steps visit: https://docs.espressif.com/projects/esptool/en/latest/troubleshooting.html
19. CMake Error at run_serial_tool.cmake:55 (message):
20.  
21.   E:/ESP/ESP-IDF/python_env/idf5.0_py3.8_env/Scripts/python.exe;;E:/ESP/ESP-IDF/frameworks/esp-idf-v5.0.1/components/esptool_py/esptool/esptool.py;--chip;esp32c3
22.   failed
23.  
24.  
25. FAILED: CMakeFiles/flash E:/ESP/projects/test/build/CMakeFiles/flash
26. cmd.exe /C "cd /D E:\ESP\ESP-IDF\frameworks\esp-idf-v5.0.1\components\esptool_py && E:\ESP\ESP-IDF\tools\cmake\3.24.0\bin\cmake.exe -D IDF_PATH=E:/ESP/ESP-IDF/frameworks/esp-idf-v5.0.1 -D SERIAL_TOOL=E:/ESP/ESP-IDF/python_env/idf5.0_py3.8_env/Scripts/python.exe;;E:/ESP/ESP-IDF/frameworks/esp-idf-v5.0.1/components/esptool_py/esptool/esptool.py;--chip;esp32c3 -D SERIAL_TOOL_ARGS=--before=default_reset;--after=hard_reset;write_flash;@flash_args -D WORKING_DIRECTORY=E:/ESP/projects/test/build -P E:/ESP/ESP-IDF/frameworks/esp-idf-v5.0.1/components/esptool_py/run_serial_tool.cmake"
27. ninja: build stopped: subcommand failed.
28. ninja failed with exit code 1, output of the command is in the e:\esp\projects\test\build\log\idf_py_stderr_output_2592 and e:\esp\projects\test\build\log\idf_py_stdout_output_2592

GeSHi © Codebox Plus Extension

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

Code: [Select all] [Expand/Collapse]

1. e:\ESP\projects\test>idf.py -p COM37 flash
2. Executing action: flash
3. Running ninja in directory e:\esp\projects\test\build
4. Executing "ninja flash"...
5. [1/5] cmd.exe /C "cd /D E:\ESP\projects\test\build\esp-idf\esptool_py && E:\ESP\ESP-IDF\python_env\idf5.0_py3.8_env\Scripts\python.exe E:/ESP/ESP-IDF/frameworks/esp-idf-v5.0.1/components/partition_table/check_sizes.py --offset 0x8000 partition --type app E:/ESP/projects/test/build/partition_table/partition-table.bin E:/ESP/projects/test/build/test.bin"
6. test.bin binary size 0x2c330 bytes. Smallest app partition is 0x100000 bytes. 0xd3cd0 bytes (83%) free.
7. [2/5] Performing build step for 'bootloader'
8. [1/1] cmd.exe /C "cd /D E:\ESP\projects\test\build\bootloader\esp-idf\esptool_py && E:\ESP\ESP-IDF\python_env\idf5.0_py3.8_env\Scripts\python.exe E:/ESP/ESP-IDF/frameworks/esp-idf-v5.0.1/components/partition_table/check_sizes.py --offset 0x8000 bootloader 0x0 E:/ESP/projects/test/build/bootloader/bootloader.bin"
9. Bootloader binary size 0x4ee0 bytes. 0x3120 bytes (38%) free.
10. [2/3] cmd.exe /C "cd /D E:\ESP\ESP-IDF\frameworks\esp-idf-v5.0.1\components\esptool_py && E:\ESP\ESP-IDF\tools\cmake\3.24.0\bin\cmake.exe -D IDF_PATH=E:/ESP/ESP-IDF/frameworks/esp-idf-v5.0.1 -D SERIAL_TOOL=E:/ESP/ESP-IDF/python_env/idf5.0_py3.8_env/Scripts/python.exe;;E:/ESP/ESP-IDF/frameworks/esp-idf-v5.0.1/components/esptool_py/esptool/esptool.py;--chip;esp32c3 -D SERIAL_TOOL_ARGS=--before=default_reset;--after=hard_reset;write_flash;@flash_args -D WORKING_DIRECTORY=E:/ESP/projects/test/build -P E:/ESP/ESP-IDF/frameworks/esp-idf-v5.0.1/components/esptool_py/run_serial_tool.cmake"
11. esptool esp32c3 -p COM37 -b 460800 --before=default_reset --after=hard_reset write_flash --flash_mode dio --flash_freq 80m --flash_size 4MB 0x0 bootloader/bootloader.bin 0x10000 test.bin 0x8000 partition_table/partition-table.bin
12. esptool.py v4.5
13. Serial port COM37
14. Connecting...
15. Chip is ESP32-C3 (revision v0.3)
16. Features: WiFi, BLE
17. Crystal is 40MHz
18. MAC: 7c:df:a1:b3:96:74
19. Uploading stub...
20. Running stub...
21. Stub running...
22. Changing baud rate to 460800
23. Changed.
24. Configuring flash size...
25. Flash will be erased from 0x00000000 to 0x00004fff...
26. Flash will be erased from 0x00010000 to 0x0003cfff...
27. Flash will be erased from 0x00008000 to 0x00008fff...
28. Compressed 20192 bytes to 12386...
29. Writing at 0x00000000... (100 %)
30. Wrote 20192 bytes (12386 compressed) at 0x00000000 in 0.3 seconds (effective 558.0 kbit/s)...
31. Hash of data verified.
32. Compressed 181040 bytes to 96207...
33. Writing at 0x00010000... (16 %)
34. Writing at 0x0001a7f8... (33 %)
35. Writing at 0x00021013... (50 %)
36. Writing at 0x00027f41... (66 %)
37. Writing at 0x0002eec9... (83 %)
38. Writing at 0x000361a8... (100 %)
39. Wrote 181040 bytes (96207 compressed) at 0x00010000 in 1.7 seconds (effective 854.3 kbit/s)...
40. Hash of data verified.
41. Compressed 3072 bytes to 103...
42. Writing at 0x00008000... (100 %)
43. Wrote 3072 bytes (103 compressed) at 0x00008000 in 0.1 seconds (effective 372.5 kbit/s)...
44. Hash of data verified.
45.  
46. Leaving...
47. Hard resetting via RTS pin...
48. Done

GeSHi © Codebox Plus Extension

[blanchehermine]

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.

[ESP_Sprite]

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?

[blanchehermine]

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:

DS2_20233227128.png (28.31 KiB) Viewed 5561 times

DS2_202332271152.png (33.96 KiB) Viewed 5561 times

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).

[ESP_Sprite]

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.

[blanchehermine]

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

In the terminal you could also write manually:

Code: Select all

openocd -f board/esp32c3-builtin.cfg -c "program_esp build/bootloader/bootloader.bin 0 verify reset exit"

Code: Select all

openocd -f board/esp32c3-builtin.cfg -c "program_esp build/partition_table/partition-table.bin 0x8000 verify reset exit"

Code: Select all

openocd -f board/esp32c3-builtin.cfg -c "program_esp build/test.bin 0x10000 verify reset exit"

But it's not convenient to type all of these commands one by one every time.

[ESP_Sprite]

Could you see what happens when you manually run esptool forcing it to use the USB-JTAG-serial dance? Something like

Code: Select all

esptool --chip esp32c3 -p COM37 -b 460800 --before=usb_reset --after=hard_reset write_flash --flash_mode dio --flash_freq 80m -flash_size 4MB 0x0 bootloader/bootloader.bin 0x10000 test.bin 0x8000 partition_table/partition-table.bin

(Specifically, the --before=usb_reset is the important bit)