Thanks for the report, can you attach or email the "TestDebug.ino_DebugOpenOCD.log" from the build folder?

Also please confirm you have done a find and replace on the attached logs for the username (some paths look a bit mangled with \_\ in).

Switched off the FS upload - used for my main application.

I added the board.txt as advised.  Still doesn't start the debugger - I get the following error message:

Unable to start debugging. Unexpected GDB output from command "-target-select remote localhost:3333". Remote communication error.  Target disconnected: error while reading: Invalid argument.

followed by another popup saying "The debugger did not start correctly, child debug processes killed"

Hi, thanks for the reply.  I can confirm that IOs 12-15 are not used for other things.  The bare board blink program uses IO 2.

I tried the new board.txt, still no success.  I also tried with my original F2232H Single, attached to my application board, but with blink program.  Error message as follows:

ESP32 PROG:
===========
After Hit start to build and debug, target board is frozen:
Unable to start debugging. Unexpected GDB output from command "-target-select remote localhost:3333". Remote communication error.  Target disconnected: error while reading: Invalid argument.

After reset target, blink again, Debug->Attach to process:
Unable to start debugging. Unexpected GDB output from command "-target-select remote localhost:3333". Remote replied unexpectedly to 'vMustReplyEmpty': vCont;c;C;s;S

F2232H Single
=============
Compile and debug:
Unable to start debugging. Unexpected GDB output from command "-target-select remote localhost:3333". Remote replied unexpectedly to 'vMustReplyEmpty': vCont;c;C;s;S

After reset, blink, attach:
Unable to start debugging. Unexpected GDB output from command "-target-select remote localhost:3333". Remote replied unexpectedly to 'vMustReplyEmpty': vCont;c;C;s;S

The manual reset was necessary for the attach debugs, as the blink app was normally frozen after the build-debug attempt.

At this point, the debugger driver seems to have got stuck as a single USB->Serial.

Switched to laptop, duplicated problem, attached OCD log file.

I notice I have the same problem as on desktop of simultaneous connection of ESP32-DEV module, and ESP32-PROG debugger results in automatic firmware upload failing.

Log is from Debug-Attach

Thanks for the update, and a bad ground between the boards definitely wont help.

When powering the ESP32 from the ESP-PROG it is best to have the ESP-PROG set to 3.3v with the jumper, and connect the power to the 3v3 pin on the ESP32.

Technically no, however it means they share the same regulated supply so can keep things more similar when trying to remove any power related issues.

The problem is down to the OpenOCD connection which can be run from the command line and shows the same as in the OpenOCD log.

Normally in these scenarios it is either:-
1) Wiring between the ESP-PROG and ESP32 being less than ideal (jumper cable wear etc)
2) Anything connected to the ESP32 causing a reset or affecting pins status on boot or the JTAG connection itself

Can you confirm which model of dev board you are using specifically?

We can also try a newer OpenOCD version however I don't believe this will solve anything for this model of board currently.

Attached image of the module.

There is nothing attached to the module apart from the JTAG connections with quite new duponts.  I have moved it to a different location on breadboard and redone the wiring just to be sure.  Power is from the ESP-PROG, switched to 3v3, connected to dev module 3v3 input.  The blink application uses IO2, which has the built-in LED.

Now, it seems there is a connect, then an abort - error msg:

Command aborted. See the output window for additional details.

Next window headed "Exception Unhandled", msg "Debugger was unable to continue the process"

Show Call Stack button shows:

>      esp_cpu_wait_for_intr() Line 64      C
     esp_vApplicationIdleHook() Line 58      C
     prvIdleTask(void * pvParameters) Line 4350      C
     vPortTaskWrapper(TaskFunction_t pxCode, void * pvParameters) Line 139      C

Hmm, that capacitor is sort of diagonal.  This is how they came.  I tried probing it with a multimeter, but did not get a stable reading, so I guess associated circuitry interferes.  My older vintage modules don't have it.

I commented out the board.txt entries, serial uploaded to ESP-DEV only, got flashing, then re-connected via ESP-PROM, and did debug attach.  Result seemed the same.  Output Debug window output:

------------------------------
openocd: Open On-Chip Debugger  v0.10.0-esp32-20190313 (2019-03-13-09:57)
openocd: Licensed under GNU GPL v2
openocd: For bug reports, read
openocd:      http://openocd.org/doc/doxygen/bugs.html
openocd: debug_level: 2
=thread-group-added,id="i1"
GNU gdb (esp-gdb) 16.3_20250913
Copyright (C) 2024 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=i686-w64-mingw32 --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".
=cmd-param-changed,param="remote hardware-watchpoint-limit",value="2"
Warning: 'flushregs', an alias for the command 'maintenance flush register-cache', is deprecated.
Use 'maintenance flush register-cache'.

Register cache flushed.
Make hw breakpoint pending on future shared library load? (y or [n]) [answered N; input not from terminal]
=cmd-param-changed,param="pagination",value="off"
tDebug.ino.elf' has changed; re-reading symbols.
0x400857b6 in esp_cpu_wait_for_intr () at mponents/esp_hw_support/cpu.c:64
Debugger was unable to continue the process.
-----------------------------------------------------------

ocd log file attached.

I should note that yesterday I went down the Copilot rabbit hole, eventually hard coding the adapter speed by adding [adapter_khz 500] at end of C:\ProgramData\vmicro\tools\openocd-espressif-esp32-10.0.1\share\openocd\scripts...

minimodule-lowcost.cfg"

This seemed to get rid of the error messages about adapter speed not being set, although in the log file, it looks like it is changed again anyway!

I'll try the serial though ESP-PROG next ...

Thanks for the update, and the Serial output is as expected.

The message about being in break mode is to ensure users know not to try and connect the serial monitor when the debugger is stopped on a breakpoint (as the MCU is effectively frozen so it cannot connect/disconnect).

The monitor output stopping when on a breakpoint is also expected as the MCU is frozen waiting for a continue message.

We can try a newer version of OpenOCD, which should work with the attached board.txt file.