[Espressif IDE/ESPC3] OpenOCD/GDB/debug suddently stop working (IEP-1115)

[ads17]

Problem description

I am working with ESPC3 on Espressif IDE, with USB-builtin-jtag. Originaly, I was using the v5.0.2 and there was no problem. Sudently, debugging became really unreliable; the vast majority of trials concluded with the exact same result as "Starting OpenOCD timed out". [Screenshot 1]

Nevertheless, when it succeed to start the debug session, either Espressif IDE freezes completely (2), either it doesn’t halt at "app_main" breakpoint and have erratic behaviour. [Screenshot 2]

What seems to me the strangest, is that openocd is working as expected onto ESP-IDF powershell: [Screenshot 3]

These are all the attempts I tried (without solving the problem..):

1. Creating a new "template" project (i used the hello world example),
2. Increase the GDB timeout through (set remotetimeout) on Debug configuration,
3. Updating to Espressif v5.1.1 using the espressif-ide-setup-2.11.0-with-esp-idf-5.1.1.exe,

To reproduce

On espressif 5.1.1.

Expected behaviour

Espressif IDE shall be able to start a debug session.

Screenshot

• Screenshot 1

• Screenshot 2

• Screenshot 3

• Screenshot 4

Espressif-IDE Product Information

product_info.txt

Eclipse Error log

errors.log

[sigmaaa]

Hi @ads17,

thank you for reporting this issue. I noticed something strange in the screenshot that the remote target port is 3334 when the gdb port is 3333. Normally this shouldn't happen. Editing the gdb port will automatically edit the target port. Try re-entering 3333 for gdb port or set port to 3334 and see if that helps.

[ads17]

Hello @sigmaaa,

Apologies for my delayed response. I was finally able to solve the issue by reverting to the original version of ESP-IDF (5.0.2) and modifying the GDB server launch timeout(s) parameter from 25 to 100 onto (Windows>Preferences>Espressif).

Previously, I was trying to modify the GDB command in the Debug configuration ("set remotetimeout xx") without any apparent effect.

In my case, the problem appeared at using the bt API, which introduced a significant delay in the launch process. I remain skeptical about upgrading to version 5.1.2 now that I have a functional workspace.

On another note, from what I understood, the debug session initializes after flash + reset. Is there a way to avoid this reset preceding the debug session? I believe that could help me avoid adjusting this timeout parameter.

[sigmaaa]

On another note, from what I understood, the debug session initializes after flash + reset. Is there a way to avoid this reset preceding the debug session? I believe that could help me avoid adjusting this timeout parameter.

Hi @ads17,

To achieve this, try to edit these options:

1. Initialization commands (Startup tab when editing the debug configuration):

• disable the initial reset and make a command like this one:

mon halt
set remote hardware-watchpoint-limit {IDF_TARGET_CPU_WATCHPOINT_NUM} 

2. Disable Pre-run/Restart reset:

Hope this helps.