This has been driving me crazy, trying to figure out why it wasn't working. I think I have it to a point where the debugger is useful, but still extremely frustrating to use.

I am mainly using an ESP-WROVER_KIT v4.1 to debug itself, but I have also run tests with the WROVER kit and an ESP_PROG as the debugger, with various ESP32 development modules as targets.  One thing I notice is that I have not been able to use the ESP32 DEVKIT as a programmer.

I have one arrangement that seems to work partially. It is the WROVER kit, running an example with no IO use.  If I Start without Debugging, then Attach to Process with a breakpoint, it will stop at the breakpoint, and I seem to be able to step around etc..  However, If I detachAll, or Stop Debugging, the VS UI freezes with the gdb and openocd tasks each maxing out a core, and VS has to be killed.  Sometimes the openocd.exe task remains running with high usage after killing VS.  BreakAll seems to do the same thing, but Terminate All seems ok.  If I have to restart VS, I also need to cycle the WROVER power and re-open the serial monitor.

It would be nice to get some pointers on how to make it a bit more usable.  Not sure what you need, but my current setup is the latest VM version and I using ESP32 core 2.0.0 (I used 2.0.3 for a while; it might work with the other changes I made, haven't tested it).  Following some forum suggestions, my local board.txt is now:

debug.toolingsystem=gdbscript
# Most stable OpenOCD Version for newer ESP32 Boards
tools.openocd.debug.path={runtime.tools.openocd-esp32-0.10.1-2021.07.21.path}
# Very Latest OpenOCD (seems less stable than the above)
# tools.openocd.debug.path={runtime.tools.openocd-esp32-0.10.1-2021.11.11.path}
# Add a delay after upload before the debugger kicks in by using a ping to ourselves as a delay (Windows has no native "sleep")
recipe.hooks.deploy.postupload.1.pattern=cmd.exe /c ping localhost -n 10
 

I am guessing that he delay is the main thing that helps, but I haven't had time to do any further experiments yet.

I will email you a dump of the build output..

Thanks for any help you can offer.
Jed

Simon,
Thanks for the reply.  With the additional lines in the board.txt, I think I get the same error as before (not 100% sure):

Uploading 'testCTCif' to 'ESP32 Wrover Kit (all versions)                                                                                           (esp32_esp32wroverkit)' using 'ESP32 DEVKIT'
Uploader started for board ESP32 Wrover Kit (all versions)                                                                                           (esp32_esp32wroverkit)
Uploader will use programmer name: esp32devkit
C:\ProgramData\vmicro\tools\openocd-esp32-0.10.1-2021.07.21\bin\openocd.exe -d2 -s ts/" -f "interface/ftdi/esp32_devkitj_v1.cfg" -f "board/esp32-wrover.cfg" -c "echo -n {****[vMicro]**** Uploading App :}" -c "telnet_port disabled; program partitions/boot_app0.bin} 0xe000" -c "echo -n {****[vMicro]**** Uploading Bootloader :}" -c "program estCTCif.ino.bootloader.bin} 0x1000" -c "echo -n {****[vMicro]**** Uploading Sketch :}" -c "program estCTCif.ino.bin} 0x10000" -c "echo -n {****[vMicro]**** Uploading Partitions :}" -c "program estCTCif.ino.partitions.bin} 0x8000 reset; shutdown"
Open On-Chip Debugger  v0.10.0-esp32-20210721 (2021-07-21-13:35)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
debug_level: 2
adapter speed: 20000 kHz
WARNING: boards/esp32-wrover.cfg is deprecated, and may be removed in a future release.
         If your board is ESP32-WROVER-KIT, use board/esp32-wrover-kit-1.8v.cfg instead.
****[vMicro]**** Uploading App :Info : ftdi: if you experience problems at higher adapter clocks, try the command "ftdi_tdo_sample_edge falling"
Info : clock speed 20000 kHz
Error: JTAG scan chain interrogation failed: all ones
Error: Check JTAG interface, timings, target power, etc.
Error: Trying to use configured scan chain anyway...
Error: esp32.cpu0: IR capture error; saw 0x1f not 0x01
Warn : Bypassing JTAG setup events due to errors
Info : Listening on port 3333 for gdb connections
Error: JTAG scan chain interrogation failed: all ones
Error: Check JTAG interface, timings, target power, etc.
Error: Trying to use configured scan chain anyway...
Error during upload using programmer
The uploader process failed

The uploader process failed
The uploader returned an error
Error: esp32.cpu0: IR capture error; saw 0x1f not 0x01
Warn : Bypassing JTAG setup events due to errors
Info : esp32.cpu0: Debug controller was reset.
Info : esp32.cpu0: Core was reset.
Error: Couldn't halt target before SoC reset
embedded:startup.tcl:449: Error: ** Unable to reset target **
in procedure 'program'
in procedure 'program_error' called at file "embedded:startup.tcl", line 486
at file "embedded:startup.tcl", line 449 

When I try to do a subsequent upload via USB, I get (in part):

WARNING: Failed to communicate with the flash chip, read/write operations will fail. Try checking the chip connections or removing any other hardware connected to IOs.
Configuring flash size...
Flash will be erased from 0x00001000 to 0x00005fff...
Flash will be erased from 0x00008000 to 0x00008fff...
Flash will be erased from 0x0000e000 to 0x0000ffff...
Flash will be erased from 0x00010000 to 0x000c6fff...
Compressed 18560 bytes to 12759...
A fatal error occurred: Packet content transfer stopped (received 8 bytes)
 

Pressing reset here gives me continual:

rst:0x10 (RTCWDT_RTC_RESET),boot:0x3e (SPI_FAST_FLASH_BOOT)
invalid header: 0xffffffff
invalid header: 0xffffffff
invalid header: 0xffffffff
invalid header: 0xffffffff
invalid header: 0xffffffff
invalid header: 0xffffffff
invalid header: 0xffffffff
ets Jul 29 2019 12:21:46 

It won't upload and the only cure is to cycle power.
When I exit debug, it now seems NOT to hang VS and Break All seems to work. I am speculating this is either due to going to core 2.0.3, and/or was due to a bug I had in my test code that hung the ESP32 (no exception or WDT or anything).  I can't imagine how that can happen, or why it would hang the IDE.

However, when I do Detach All or Stop Debugging, the target hangs, even if there are no active breakpoints.  Reconnecting the serial monitor does nothing, and doing an RTS reset gets back to the "invalid header" resets.  HW reset too. Again, I have to cycle the power.

I'm not in a position to test other modules at the moment, but if you think it will help I can do so.

Regards,
Jed