ESP32S3 OpenOCD debugging with internal USB-JTAG interface hangs in ROM loader

[arex-ebee]

Hi all,

not quite sure whether this is the right place for the topic but I'll try my luck.

environment is
IDF 5.2.5
Debian 12
ESP32-S3-WROOM-1 (N16R2) module on own HW

Due to a tricky issue we've observed in our target device I began to try the JTAG debugging capabilities of the ESP32S3 what seems to be quite simple to start due to its internal USB-JTAG bridge device. Studying the according IDF documentation at https://docs.espressif.com/projects/esp ... index.html I had quick success when trying to perform single step debugging with the the "blink" example application.

After I had set up, built and flashed the example application I performed following steps while the ESP32 module's USB pins were connected to the host PC:

Code: Select all

idf.py openocd

...and on a second terminal:

Code: Select all

idf.py gdb

Nothing more to say, just that it expectedly stopped in app_main() function waiting for further input from gdb console:

Code: Select all

$ idf.py gdb
Executing action: gdb
GNU gdb (esp-gdb) 14.2_20240403
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-linux-gnu --target=xtensa-esp-elf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word".
add symbol table from file "/espressif/esp-idf/examples/get-started/blink/build/bootloader/bootloader.elf"
0x40000400 in ?? ()
add symbol table from file "/.espressif/tools/esp-rom-elfs/20230320/esp32s3_rev0_rom.elf"
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)
[esp32s3.cpu0] requesting target halt and executing a soft reset
[esp32s3.cpu0] Debug controller was reset.
[esp32s3.cpu0] Core was reset.
[esp32s3.cpu0] Target halted, PC=0x500000EF, debug_reason=00000000
[esp32s3.cpu0] Reset cause (3) - (Software core reset)
[esp32s3.cpu0] Core was reset.
[esp32s3.cpu0] Target halted, PC=0x40000400, debug_reason=00000000
[esp32s3.cpu1] Debug controller was reset.
[esp32s3.cpu1] Core was reset.
[esp32s3.cpu1] Target halted, PC=0x40000400, debug_reason=00000000
[esp32s3.cpu1] Reset cause (3) - (Software core reset)
[esp32s3.cpu0] Reset cause (3) - (Software core reset)
Hardware assisted breakpoint 1 at 0x42008438: file /espressif/esp-idf/examples/get-started/blink/main/blink_example_main.c, line 92.
[esp32s3.cpu0] Target halted, PC=0x42008438, debug_reason=00000001
Set GDB target to 'esp32s3.cpu0'
[esp32s3.cpu1] Target halted, PC=0x40378F1E, debug_reason=00000000
[New Thread 1070179128]
[Remote target exited]
[New Thread 1070182896]
[New Thread 1070181012]
[New Thread 1070170176]
[New Thread 1070174620]
[New Thread 1070168548]
[Switching to Thread 1070179128]

Thread 2 "main" hit Temporary breakpoint 1, app_main () at /espressif/esp-idf/examples/get-started/blink/main/blink_example_main.c:92
92      {
(gdb) bt
#0  app_main () at /espressif/esp-idf/examples/get-started/blink/main/blink_example_main.c:92
#1  0x4201b19a in main_task (args=0x0) at /espressif/esp-idf/components/freertos/app_startup.c:208
#2  0x4037b258 in vPortTaskWrapper (pxCode=0x4201b0f0 <main_task>, pvParameters=0x0) at /espressif/esp-idf/components/freertos/FreeRTOS-Kernel/portable/xtensa/port.c:139
(gdb) 

After succeeding with this quick test I loaded our target application onto the HW (idf.py flash). Now performing the same steps as above I observe strange results: When gdb connects to the OpenOCD server it correctly sets the first breakpoint at app_main() but never reaches it. Instead the gdb initialization doesn't end up at its console but keeps busy. Pressing Ctrl-C obviously interrupts the running program where the current backtrace indicates that the ESP still runs in its ROM loader:

Code: Select all

$ idf.py gdb
Executing action: gdb
GNU gdb (esp-gdb) 14.2_20240403
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-linux-gnu --target=xtensa-esp-elf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word".
add symbol table from file "/app_main/build/bootloader/bootloader.elf"
0x40041a76 in ?? ()
add symbol table from file "/.espressif/tools/esp-rom-elfs/20230320/esp32s3_rev0_rom.elf"
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)
[esp32s3.cpu1] Unexpected OCD_ID = 00000000
[esp32s3.cpu0] requesting target halt and executing a soft reset
[esp32s3.cpu0] Debug controller was reset.
[esp32s3.cpu0] Core was reset.
[esp32s3.cpu0] Target halted, PC=0x500000EF, debug_reason=00000000
[esp32s3.cpu0] Reset cause (3) - (Software core reset)
[esp32s3.cpu0] Core was reset.
[esp32s3.cpu0] Target halted, PC=0x40000400, debug_reason=00000000
[esp32s3.cpu1] Debug controller was reset.
[esp32s3.cpu1] Core was reset.
[esp32s3.cpu1] Target halted, PC=0x40000400, debug_reason=00000000
[esp32s3.cpu1] Reset cause (3) - (Software core reset)
[esp32s3.cpu0] Reset cause (3) - (Software core reset)
Hardware assisted breakpoint 1 at 0x4200deb8: file /app_main/src/main/main.c, line 1043.

^C  <<---------- interrupted via Ctrl-C
[esp32s3.cpu0] Target halted, PC=0x40041A79, debug_reason=00000000
Set GDB target to 'esp32s3.cpu0'
[esp32s3.cpu1] Target halted, PC=0x40043A40, debug_reason=00000000

Program received signal SIGINT, Interrupt.
0x40041a79 in ets_delay_us ()
(gdb) bt
#0  0x40041a79 in ets_delay_us ()
#1  0x40047b51 in UartConnCheck ()
#2  0x4004397f in detect_uart_usb_spi_boot_mode ()
#3  0x40043c36 in main ()
#4  0x40034c48 in _start ()
(gdb) 

As JTAG debugging works with the example application on the same HW it must have anything to do with our application's configuration. At that point I have to say that our application actually also uses the USB port of the ESP32 (either host or device). But with this knowledge in mind I ensured that according USB init code is not run or even not compiled in. Anyhow I don't have any clue what could make the ESP32 staying in its ROM loader when connecting via gdb.

So my question is if anyone of you guys already had similar experience that JTAG debugging ended up in not leaving the ROM loader? I'd appreciate any helpful indication where to look further.

Cheers
André

[arex-ebee]

Hi @Harbal,

thanks for your response. To be honest, I'm afraid I don't really understand what you mean by your hint. How could the USB config keep the ESP32 in download mode? Could you provide me a clue where I have to look at?

Cheers
André