Native USB debug interface mimicked on my own PCB fails

t_magdahl · July 13, 2026, 9:20pm

Hi,

My environment is:
VSC+PlatformIO+
platform = https://github.com/pioarduino/platform-espressif32/releases/download/55.03.38-1/platform-espressif32.zip

The ini and log blocks in the post can be skipped and the regular text has I think the relevant aspects so somebody more experienced can spot the problem.

I am only using one USB cable on the native USB port of an ESP32-S3-DevKitC-1 module, I have been able to do upload and debug or print without any problems. During debug, print would only work if running free over the print statements, but not in step mode over them, which is not a big deal. Debug would stop at setup() flawlessly. I would compile and upload, and then perform DEBUG (without upload).
The module would always have the interface-0 and interface-2 (libusbk) correctly set (W11 might have learned to enumerate it correctly) and at any time (after stopping the debugger) I can do a new upload and then a debug (without uploading) without ever having to press any of the module’s BOOT or RESET buttons.
This is the PlatformIO INI file (Some comments are old and eventually wrong due to zillion of changes requested by AI)

; --- COMMON SETTINGS ---
; These are shared to keep both environments in sync
[env]
; Check this site for updated platforms (newer)
; https://github.com/sivar2311/platform-espressif32-versions
platform = https://github.com/pioarduino/platform-espressif32/releases/download/55.03.38-1/platform-espressif32.zip
;platform = https://github.com/pioarduino/platform-espressif32/releases/download/55.03.37/platform-espressif32.zip
;platform = espressif32
board = esp32-s3-devkitc1-n8r2-dts
framework = arduino
monitor_speed = 115200

; 1. Force PlatformIO to scan deep inside library source files aggressively
lib_ldf_mode = deep+

lib_deps =
    adafruit/Adafruit FRAM SPI@^2.6.2
    adafruit/Adafruit NeoPixel@^1.15.4
    fbiego/ESP32Time@^2.0.6
    Wire

; --- NORMAL RUNNING (Release) ---
[env:release]
build_type = release
build_flags = 
    -Os
    -DARDUINO_USB_CDC_ON_BOOT=1
    -DARDUINO_USB_MODE=1
    -DNDEBUG                  ; Disables assert() macros for speed
    -fno-exceptions           ; Reduces binary size if not using C++ exceptions

;

; --- DEBUGGING (Stable Config) ---
[env:DEBUG]
build_type = debug

; Flags to help Windows 11 keep the USB stack stable
build_flags = 
    -O0
    -g3
    -ggdb
    -DDEBUG
    -DARDUINO_USB_CDC_ON_BOOT=1
    -DARDUINO_USB_DFU_ON_BOOT=1
    -DARDUINO_USB_MODE=0            ; Use "Hardware CDC and JTAG"
    -DCORE_DEBUG_LEVEL=4            ; Sets log level to Verbose (adjust as needed)

;debug_tool = esp-builtin
;upload_protocol = esp-builtin
;debug_speed = 10000
debug_speed = 2000

;;;;; START OF NEW STUFF
upload_protocol = custom
upload_command = "${platformio.packages_dir}/tool-openocd-esp32/bin/openocd" -s "${platformio.packages_dir}/tool-openocd-esp32/share/openocd/scripts" -f board/esp32s3-builtin.cfg -c "adapter speed 10000" -c "program_esp .pio/build/DEBUG/firmware.bin 0x10000 verify" -c "reset run" -c "shutdown"

debug_tool = custom
debug_server = 
    ${platformio.packages_dir}/tool-openocd-esp32/bin/openocd
    -s
    ${platformio.packages_dir}/tool-openocd-esp32/share/openocd/scripts
    -f
    board/esp32s3-builtin.cfg
    -c
    adapter speed 2000
;    adapter speed 10000

debug_port = localhost:3333
;;;;; END OF NEW STUFF

debug_load_mode = manual
debug_init_break = tbreak setup

; When we start the Serial Monitor we do not want a COM port reset that afects the debugger
monitor_dtr = 0
monitor_rts = 0

; Remove 'monitor reset halt', it is likely what's crashing the W11 driver
debug_extra_cmds = 
    set remotetimeout 20
    flushregs

This is the successful DEBUG LOG after stopping at setup().

Memory Map (8 regions): 
---------------------------------------- 
Type Start Addr Length BlockSize 
---------------------------------------- 
FLASH 0x00000000 0x00800000 0x00001000 
R/W 0x00800000 0x3b860000 0x00000000 
FLASH 0x3c060000 0x00028000 0x00001000 
R/W 0x3c088000 0x03f78000 0x00000000 
ROM 0x40000000 0x00060000 0x00000000 
R/W 0x40060000 0x01fa0000 0x00000000 
FLASH 0x42000000 0x0005e000 0x00001000 
R/W 0x4205e000 0xbdfa2000 0x00000000 
---------------------------------------- 
0x4037ce0a in esp_cpu_wait_for_intr () at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/esp_hw_support/cpu.c:64 
warning: 64 /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/esp_hw_support/cpu.c: No such file or directory 
Info : Detected FreeRTOS version: (10.5.1) 
Info : JTAG tap: esp32s3.tap0 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1) 
Info 
JTAG tap: esp32s3.tap0 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1) 
: JTAG tap: esp32s3.tap1 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1) 
JTAG tap: esp32s3.tap1 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1) 
Info : [esp32s3.cpu0] requesting target halt and executing a soft reset 
[esp32s3.cpu0] requesting target halt and executing a soft reset 
Info : [esp32s3.cpu0] Debug controller was reset. 
[esp32s3.cpu0] Debug controller was reset. 
Info : [esp32s3.cpu0] Core was reset. 
[esp32s3.cpu0] Core was reset. 
Info : [esp32s3.cpu0] Target halted, PC=0x500000EF, debug_reason=00000000 
[esp32s3.cpu0] Target halted, PC=0x500000EF, debug_reason=00000000 
Info : [esp32s3.cpu0] Reset cause (3) - (Software core reset) 
[esp32s3.cpu0] Reset cause (3) - (Software core reset) 
Info : [esp32s3.cpu0] Core was reset. 
[esp32s3.cpu0] Core was reset. 
Info : [esp32s3.cpu0] Target halted, PC=0x40000400, debug_reason=00000000 
[esp32s3.cpu0] Target halted, PC=0x40000400, debug_reason=00000000 
Info : [esp32s3.cpu1] Debug controller was reset. 
[esp32s3.cpu1] Debug controller was reset. 
Info : [esp32s3.cpu1] Core was reset. 
[esp32s3.cpu1] Core was reset. 
Info : [esp32s3.cpu1] Target halted, PC=0x40000400, debug_reason=00000000 
[esp32s3.cpu1] Target halted, PC=0x40000400, debug_reason=00000000 
Info : [esp32s3.cpu1] Reset cause (3) - (Software core reset) 
[esp32s3.cpu1] Reset cause (3) - (Software core reset) 
Info : [esp32s3.cpu0] Reset cause (3) - (Software core reset) 
[esp32s3.cpu0] Reset cause (3) - (Software core reset) 
Temporary breakpoint 1 at 0x42007ff0: file src/main.cpp, line 47. 
Note: automatically using hardware breakpoints for read-only addresses. 
Warning: 'flushregs', an alias for the command 'maintenance flush register-cache', is deprecated. 
Use 'maintenance flush register-cache'. 
PlatformIO: Initialization completed 
PlatformIO: Resume the execution to `debug_init_break = tbreak setup` 
PlatformIO: More configuration options -> https://bit.ly/pio-debug 
Info : [esp32s3.cpu0] Target halted, PC=0x4037CE0A, debug_reason=00000000 
[esp32s3.cpu0] Target halted, PC=0x4037CE0A, debug_reason=00000000 
Info : Set GDB target to 'esp32s3.cpu0' 
Set GDB target to 'esp32s3.cpu0' 
Info : [esp32s3.cpu1] Target halted, PC=0x42007FF0, debug_reason=00000001 
[esp32s3.cpu1] Target halted, PC=0x42007FF0, debug_reason=00000001 
Info : Detected FreeRTOS version: (10.5.1) 
[New Thread 1070529176] 
[Remote target exited] 
[New Thread 1070265052] 
[New Thread 1070266548] 
[New Thread 1070243052] 
[New Thread 1070270060] 
[New Thread 1070257396] 
[New Thread 1070246116] 
[New Thread 1070241620] 
[Switching to Thread 1070529176] 
Thread 2 "loopTask" hit Temporary breakpoint 1, setup () at src/main.cpp:47 
47 void setup() {

Long time ago inspecting the ESP32-S3-DevKitC-1 schematic I noticed that the native USB port had only D+ (IO20) and D- (IO19) wired, which I included in my own PCB design. Additionally, I provided in my PCB design an automatic reset of the CPU at power up/brown out (reset supervisor chip) and a manual reset by means of a button, linked to the same supervisor chip.
At power up my PCB has a correct interface-0 and interface-2.
Only difference, instead of COM3, my PCB loads interface-0 on COM8, not sure why? Module ESP32-S3-DevKitC-1 has an ESP32-S3-WROOM-1-N8R2 and my PCB has the same module.

My issue is that on my own PCB I can upload the code exactly as with DevKitC. After an upload I can repeat a second one immediately. But maybe my INI file would not let me reach a consistent debugger stop at setup().

This is the debugger LOG when using my own PCB.
Notice that the 19 last lines of the successful LOG are missing when attempting to DEBUG my own PCB after the upload of the DEBUG version.

Memory Map (8 regions): 
---------------------------------------- 
Type Start Addr Length BlockSize 
---------------------------------------- 
FLASH 0x00000000 0x00800000 0x00001000 
R/W 0x00800000 0x3b860000 0x00000000 
FLASH 0x3c060000 0x00028000 0x00001000 
R/W 0x3c088000 0x03f78000 0x00000000 
ROM 0x40000000 0x00060000 0x00000000 
R/W 0x40060000 0x01fa0000 0x00000000 
FLASH 0x42000000 0x0005e000 0x00001000 
R/W 0x4205e000 0xbdfa2000 0x00000000 
---------------------------------------- 
0x4037ce0a in esp_cpu_wait_for_intr () at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/esp_hw_support/cpu.c:64 
warning: 64 /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/esp_hw_support/cpu.c: No such file or directory 
Info : Detected FreeRTOS version: (10.5.1) 
Info : JTAG tap: esp32s3.tap0 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1) 
Info 
JTAG tap: esp32s3.tap0 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1) 
: JTAG tap: esp32s3.tap1 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1) 
JTAG tap: esp32s3.tap1 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1) 
Info : [esp32s3.cpu0] requesting target halt and executing a soft reset 
[esp32s3.cpu0] requesting target halt and executing a soft reset 
Info : [esp32s3.cpu0] Debug controller was reset. 
[esp32s3.cpu0] Debug controller was reset. 
Info : [esp32s3.cpu0] Core was reset. 
[esp32s3.cpu0] Core was reset. 
Info : [esp32s3.cpu0] Target halted, PC=0x500000EF, debug_reason=00000000 
[esp32s3.cpu0] Target halted, PC=0x500000EF, debug_reason=00000000 
Info : [esp32s3.cpu0] Reset cause (3) - (Software core reset) 
[esp32s3.cpu0] Reset cause (3) - (Software core reset) 
Info : [esp32s3.cpu0] Core was reset. 
[esp32s3.cpu0] Core was reset. 
Info : [esp32s3.cpu0] Target halted, PC=0x40000400, debug_reason=00000000 
[esp32s3.cpu0] Target halted, PC=0x40000400, debug_reason=00000000 
Info : [esp32s3.cpu1] Debug controller was reset. 
[esp32s3.cpu1] Debug controller was reset. 
Info : [esp32s3.cpu1] Core was reset. 
[esp32s3.cpu1] Core was reset. 
Info : [esp32s3.cpu1] Target halted, PC=0x40000400, debug_reason=00000000 
[esp32s3.cpu1] Target halted, PC=0x40000400, debug_reason=00000000 
Info : [esp32s3.cpu1] Reset cause (3) - (Software core reset) 
[esp32s3.cpu1] Reset cause (3) - (Software core reset) 
Info : [esp32s3.cpu0] Reset cause (3) - (Software core reset) 
[esp32s3.cpu0] Reset cause (3) - (Software core reset) 
Temporary breakpoint 1 at 0x42007ff0: file src/main.cpp, line 47. 
Note: automatically using hardware breakpoints for read-only addresses. 
Warning: 'flushregs', an alias for the command 'maintenance flush register-cache', is deprecated. 
Use 'maintenance flush register-cache'. 
PlatformIO: Initialization completed 
PlatformIO: Resume the execution to `debug_init_break = tbreak setup` 
PlatformIO: More configuration options -> https://bit.ly/pio-debug 
Info : [esp32s3.cpu0] Target halted, PC=0x4037CE0A, debug_reason=00000000 
[esp32s3.cpu0] Target halted, PC=0x4037CE0A, debug_reason=00000000 
Info : Set GDB target to 'esp32s3.cpu0' 
Set GDB target to 'esp32s3.cpu0' 
Info : [esp32s3.cpu1] Target halted, PC=0x42007FF0, debug_reason=00000001 
[esp32s3.cpu1] Target halted, PC=0x42007FF0, debug_reason=00000001 
Info : Detected FreeRTOS version: (10.5.1) 
[New Thread 1070529176] 
[Remote target exited] 
[New Thread 1070265052] 
[New Thread 1070266548] 
[New Thread 1070243052] 
[New Thread 1070270060] 
[New Thread 1070257396] 
[New Thread 1070246116] 
[New Thread 1070241620] 
[Switching to Thread 1070529176] 
Thread 2 "loopTask" hit Temporary breakpoint 1, setup () at src/main.cpp:47 
47 void setup() {

If at the debugger toolbox I press pause, I get these additional LOG lines

Info : [esp32s3.cpu0] Target halted, PC=0x40041A7C, debug_reason=00000000 
[esp32s3.cpu0] Target halted, PC=0x40041A7C, debug_reason=00000000 
Info : Set GDB target to 'esp32s3.cpu0' 
Set GDB target to 'esp32s3.cpu0' 
Info : [esp32s3.cpu1] Target halted, PC=0x40043A3B, debug_reason=00000000 
[esp32s3.cpu1] Target halted, PC=0x40043A3B, debug_reason=00000000 
Warn : esp_symbols table size (165) is bigger than expected (16) 
Program 
received signal SIGINT, Interrupt. 
0x40041a7c in ?? ()

The only difference between both boards is that in my PCB a supervisor chip is managing EN with a push-pull gate (no resistor between the supervisor and the EN pin) and DevKitC has an RC network. In case some native USB module in the CPU, when starting the DEBUG session, is trying to reset the cores pulling EN low, it will fail in my case because the supervisor will not allow the pin to go LOW or will “fight” against.
Might this be my problem? I still have a native JATG interface option and using an ESP32-PROG board, but not sure if it will fail due to the supervisor too.

t_magdahl · July 14, 2026, 12:48pm

I just found this answer at the ESP32 site.

During DEBUG I understand the USB Serial/JTAG controller will reset the CPU cores. If EN is driven by a supervisor chip and the supervisor is keeping it high (already booted), will the JTAG controller be able to reset the CPU?

Yes — the USB Serial/JTAG controller can reset the CPU cores independently of the EN pin.

How It Works

The JTAG command processor has a dedicated SRST line that is connected directly to the reset logic of the digital circuitry in the SoC. Setting SRST high via the CMD_RST command causes a digital system reset — this does not involve the EN (CHIP_PU) pin at all. [ESP32-S3 TRM]

Similarly, the CDC-ACM interface can reset the ESP32-S3 by manipulating the RTS/DTR lines on the virtual serial port. According to the truth table:

RTS	DTR	Action
1	0	Reset ESP32-S3
0	1	Set download mode flag

This reset is also triggered internally and does not require toggling the EN pin. [ESP32-S3 TRM]

Reset Type Involved

From the reset source table, the resets triggered via USB Serial/JTAG are:

USB (UART) reset (0x15): Core Reset — triggered when the USB host sends a specific command to the Serial interface.
USB (JTAG) reset (0x16): Core Reset — triggered when the USB host sends a specific command to the JTAG interface.

Both are Core Resets, meaning they reset the whole digital system (CPU0, CPU1, peripherals, Wi-Fi, BLE, digital GPIOs) except RTC. [ESP32-S3 TRM]

Summary

So even if your supervisor chip is holding EN high and will never release it, the USB Serial/JTAG controller can still reset the CPU cores through its internal reset path. Your debug workflow should be unaffected.