Thanks for this report and the brilliant level of detail!!

Configuration File Issue
We have the wrong *.cfg configured for this setup currently ("ftdi/olimex-jtag-tiny-h.cfg" instead of "ftdi/olimex-arm-usb-tiny-h.cfg"), and we will amend this as there is already an existing *.cfg with the correct settings as described in your launch_JSON (thanks for this!).

To work around this currently you can:
1) Select the vMicro > Debugger > Hardware Debugger: Olimex ARM-USB-TINY-H
2) Use vMicro > Add Code > Add Local Board.txt, and add the lines in the attached file in, then save the file.
3) Try attaching the debugger again and this should now work as expected.

We will update this thread when the fix is released (which affects Board Packages ESP32, Mbed_Nano, Mbed_RP2040).

Reset Before Re-Attach Debugger
This should be improved in the very latest version of Visual Micro, which has a minor change as to how it kills the debugging session when pressing the Stop Debugging button (now it leaves the board code running, instead of totally killing the application which often causes the need to reset the board again before re-attaching).

Simon, 

After updating to version 2022.1128.2225 of visual micro I believe that the olimex debugger is no longer working.  Is there a way to roll back visual micro so I can check if this is the case?  I tried debugging on another project and was unable to do so.  When I went back to the original (simpler project) and attempted to debug using the files you provided this also failed.

I am getting the error, "unable to start debugging. Unexpected GDB outptut from command "-target-select remote localhost:3333". localhost:3333:(undocumented errno 138).

Thanks for the update.

If the debugging session ends unexpectedly or it fails to attach, sometimes there can be orphaned processes left running for xtensa-esp32-elf-gdb.exe which can prevent the debugger from attaching.  If you kill these via task manager this should resolve the problem if it is that.

There was also a minor change in the latest (*.25) version of Visual Micro which should now leave the code on the ESP32 running after stopping the debugging session. Previous to this it killed the code on the target which could leave it in an unusable state, but from your description I don't believe this is the issue, but worth noting.