Solved: Debugging with ESP-Prog used to work but not now!

PlatformIO Core 5.0.4 Home 3.3.1
SUSE Leap 15.2
The hardware is a ESP32-WROOM-32D module on a “no-name” burner board.

[platformio]
description = My Blink
[env:esp32dev]
platform = espressif32
board = esp32dev
framework = arduino
lib_extra_dirs = ~/Documents/Arduino/libraries
upload_protocol = esp-prog
upload_port = /dev/ttyUSB1
upload_speed = 115200
monitor_port = /dev/ttyUSB1
monitor_speed = 115200
debug_tool = esp-prog
debug_port = /dev/ttyUSB0
debug_init_break = tbreak

My Debug Console…

Preparing firmware for debugging...
Processing esp32dev (platform: espressif32; board: esp32dev; framework: arduino)
--------------------------------------------------------------------------------
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/espressif32/esp32dev.html
PLATFORM: Espressif 32 (2.1.0) > Espressif ESP32 Dev Module
HARDWARE: ESP32 240MHz, 320KB RAM, 4MB Flash
DEBUG: Current (esp-prog) External (esp-prog, iot-bus-jtag, jlink, minimodule, olimex-arm-usb-ocd, olimex-arm-usb-ocd-h, olimex-arm-usb-tiny-h, olimex-jtag-tiny, tumpa)
PACKAGES:
 - framework-arduinoespressif32 3.10004.201016 (1.0.4)
 - tool-esptoolpy 1.30000.201119 (3.0.0)
 - tool-openocd-esp32 2.1000.20201202 (10.0)
 - toolchain-xtensa32 2.50200.80 (5.2.0)
LDF: Library Dependency Finder -> http://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 26 compatible libraries
Scanning dependencies...
No dependencies
Building in debug mode
Retrieving maximum program size .pio/build/esp32dev/firmware.elf
Checking size .pio/build/esp32dev/firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [          ]   4.7% (used 15444 bytes from 327680 bytes)
Flash: [==        ]  16.5% (used 216797 bytes from 1310720 bytes)
========================= [SUCCESS] Took 1.93 seconds =========================
undefinedOpen On-Chip Debugger  v0.10.0-esp32-20201202 (2020-12-02-17:38)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
adapter speed: 20000 kHz

WARNING: boards/esp-wroom-32.cfg is deprecated, and may be removed in a future release.
Info : FreeRTOS creation
adapter speed: 20000 kHz

Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : ftdi: if you experience problems at higher adapter clocks, try the command "ftdi_tdo_sample_edge falling"
Info : clock speed 20000 kHz
Info : JTAG tap: esp32.cpu0 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
Info : JTAG tap: esp32.cpu1 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
Info : Listening on port 3333 for gdb connections
Reading symbols from /home/mprowe/Documents/PlatformIO/Projects/myBlink_FT231/.pio/build/esp32dev/firmware.elf...
done.
PlatformIO Unified Debugger -> http://bit.ly/pio-debug
PlatformIO: debug_tool = esp-prog
PlatformIO: Initializing remote target...
.pioinit:11: Error in sourced command file:
/dev/ttyUSB0: No such file or directory.

I know that it (last line above) reports that there is a problem with /dev/ttyUSB0!
But before I try running Debug (Run | Start Debugging) both ports on the ESP_Prog are reported.
After the debug port (/dev/ttyUSB0) vanishes following the failed debug session, if I close and reopening PIO, /dev/ttyUSB0 is back again.
And lastly, I’m fairly sure that my setup was working fine only a week ago?

Regards, M.

Just remove that line.

Your debug port is not a serial port, it’s the USB device (the FTDI FT2232H). That USB device has two “channels” which can bei either JTAG or UART. When OpenOCD is started it reconfigures one of those channels and thus you (correctly) loose one serial adapter device.

Same goes for upload_port (if you wish to upload via JTAG).

If you have it connected via UART and want to flash via UART, you need to remove the xxx = esp-prog lines.

Dho…!
I thought I was being thorough by (sorta) documenting what I thought was happening.

Thank you yet again, M.