Can't upload code if ESP-Prog USB cable is plugged in

I using PlatformIO on Ubuntu 20.04. I have an ESP-Prog JTAG debugger hooked to Pins 12, 13, 14, and 15 of my Adafruit Huzzah Feather ESP32 board. I can build Arduino framework test programs fine but I can not upload them to the board unless I first unplug the USB cable between the ESP-Prog and my laptop. Once I do this, the upload will work, then I can plug in the cable and start the debug. While this is mostly a pain, it really becomes a pain when using PlatformIO in a KVM-qemu virtual machine. Unplugging cables from VMs is a problem.

Any solution to this?
my .ini file is:
[env:featheresp32]
platform = espressif32
board = featheresp32
framework = arduino
monitor_speed = 114200
upload_port = /dev/ttyUSB0
upload_speed = 921600
debug_tool = esp-prog
debug_init_break = tbreak setup

Hm I don’t have the hardware to verify that at the moment but here are some thoughts: If the uploading fails because of a packet timeout error (aka, “no response from the bootloader”), it may be because the ESP-PROG is driving some of the required lines, like reset/enable or the flash voltage, to the wrong level, and it prevents the serial uploader to do an upload. If the error message is different, please post it here. Or, it could also be that upload_port = /dev/ttyUSB0 is wrong depending on what devices are plugged in.

Otherwise, there’s a pragmatic workaround: Upload via the esp-prog, too, see docs. So, setting upload_protocol = esp-prog and removing the upload_port should do the trick. You can still leave the usb cable for the serial connection plugged in so that you have your serial monitor, but it shouldn’t affect JTAG uploading anymore.

This seems unusual btw, since the next standard baudrate is 115200 – typo?

Yes it’s a typo, so I fixed it in the .ini file. Oddly that part worked. However, I rebooting and for some reason it’s working solidly now. It must be because I posted an issue about it. The computer is always trying to make a liar out of me. :grinning:

Rebooting may have also changed the order of the /dev/ttyUSB0 / 1 device and thus made it work if it was previously trying to upload via the unconnected COM port on the ESP-PROG. The ESP-PROG also has a serial port and shows up as one. If you want to save a USB cable, then you can also use the COM port there and connect it to the board :smiley: (see docs).

Now it’s decided not to update anymore if the ESP-Prog cable is plugged in. So it definitely works part of the time, but not always.

Current error is:

Configuring upload protocol…
AVAILABLE: esp-prog, espota, esptool, iot-bus-jtag, jlink, minimodule, olimex-arm-usb-ocd, olimex-arm-usb-ocd-h, olimex-arm-usb-tiny-h, olimex-jtag-tiny, tumpa
CURRENT: upload_protocol = esptool
Looking for upload port…
Use manually specified: /dev/ttyUSB0
Uploading .pio/build/featheresp32/firmware.bin
esptool.py v3.0
Serial port /dev/ttyUSB0
Connecting…
Traceback (most recent call last):
File “/home/jim/.platformio/packages/tool-esptoolpy/esptool.py”, line 3969, in
_main()
File “/home/jim/.platformio/packages/tool-esptoolpy/esptool.py”, line 3962, in _main
main()
File “/home/jim/.platformio/packages/tool-esptoolpy/esptool.py”, line 3552, in main
esp.connect(args.before, args.connect_attempts)
File “/home/jim/.platformio/packages/tool-esptoolpy/esptool.py”, line 522, in connect
last_error = self._connect_attempt(mode=mode, esp32r0_delay=True)
File “/home/jim/.platformio/packages/tool-esptoolpy/esptool.py”, line 493, in _connect_attempt
self._setDTR(False) # IO0=HIGH, done
File “/home/jim/.platformio/packages/tool-esptoolpy/esptool.py”, line 443, in _setDTR
self._port.setDTR(state)
File “/home/jim/.platformio/penv/lib/python3.8/site-packages/serial/serialutil.py”, line 603, in setDTR
self.dtr = value
File “/home/jim/.platformio/penv/lib/python3.8/site-packages/serial/serialutil.py”, line 473, in dtr
self._update_dtr_state()
File “/home/jim/.platformio/penv/lib/python3.8/site-packages/serial/serialposix.py”, line 715, in _update_dtr_state
fcntl.ioctl(self.fd, TIOCMBIC, TIOCM_DTR_str)
OSError: [Errno 5] Input/output error
*** [upload] Error 1

Thanks, I see your point. Your reference helped as well. I think I need to make a change to the .ini file if I want to upload via the ESP-Prog port.

upload_protocol = esp-prog

I now have to see how to power the Feather ESP32. It is not designed to be power by external power supplies, except USB or LiPoly battery. I’ll play with it and see what happens.

I’m not having any success with using only the USB port on the ESP-Prog but that isn’t really critical. I think it’s got mostly to due with which USB cable is plugged in first. I’ll play with it more today to see if I can come up with exactly how and when to plug things up and when to power things up.

to close this out, I have a workaround that mostly works most of the time.
Since I like to have the USB Serial console as an output for high-level debug messages, and I have to power the ESP32 board I have that board’s USB connected to the PC. I do this first. Then I open VSCode and build and upload the code with an .ini file that reads:

[env:featheresp32]
platform = espressif32
board = featheresp32
framework = arduino
monitor_speed = 115200
build_type = debug
debug_tool = esp-prog
debug_init_break = tbreak setup

After the code has uploaded I connect the ESP-Prog USB cable and start debug. At this point, I usually can stop debug, edit the program, recompile and upload without removing the ESP-Prog USB cable.

I did get it working reliably using the ESP-Prog USB cable only by putting in the

upload_protocol = esp-prog

statement into the platformio.ini file, but you lose the USB port for printf and you still have to power the board with USB anyway.

Per linked doc page of the ESP-PROG has the possibility to power the target board, plus the Feather ESP32 board has the same UART TX/RX lines exposed that go to the internal USB-Serial chip, you can attach to those same lines (TX+RX) and really have only one USB cable / device for upload+debugging+serialoutput+power.

The Feather ESP32, per schematics, has the “USB” pin through which you can feed 5V (with a shared GND of course). If you jumper SEL 5V on the ESP-PROG the “VDD” pin on the JTAG pin header will have 5V for powering.

Seems like esptoolpy failed when trying to drive the DTR pin of the serial chip – maybe /dev/ttyUSB0 was the wrong serial port, of you have a driver issue.

thanks, I have it hooked up with only the USB cable to the ESP-Prog. I have the ESP-Prog set to 5V for the JTAG connector and the VDD from that connector jumper-ed to the USB pin on the Feather ESP32 board.

I also have the TX,RX jumper-ed from the ESP-Prog Interface to the RX/TX of my ESP32 Feather. However I had to change the code from Serial.print to Serial1.print. Adafruit states that the USB Serial port is not the same as what’s on pins 16 and 17. I now see serial output in the PlatformIO Serial Monitor display coming from /dev/ttyUSB1. I also can upload the code but is slower and has some warnings.

The problem now is the debugging. Some times it enters debugging mode and some times it doesn’t. It also sometimes generates errors and just gets lost. Before I start posting a bunch of errors, I’ll show my current .ini to see if you find a mistake there.

[env:featheresp32]
platform = espressif32
board = featheresp32
framework = arduino
monitor_speed = 115200
monitor_port = /dev/ttyUSB1
upload_protocol = esp-prog
build_type = debug
debug_tool = esp-prog
debug_init_break = tbreak setup

Ah indeed, schematics show that TXD0/RXD0 are only internal and not exposed on a header.

Hm a general countermeasure with instability is to always lower the debug_speed parameter, to e.g. debug_speed = 600. Otherwise we would need to see the error messages.

the debug_speed = 600 really slowed things down including the programming. Once you get to the start of debugging with a break at the first statement, I can put in a breakpoint, like normal. but after the first stop at a breakpoint I set, it never stops. I see this in the debug console.

Info : esp32.cpu0: Debug controller was reset.
Info : esp32.cpu0: Core was reset.
Info : esp32.cpu1: Debug controller was reset.
Info : esp32.cpu1: Core was reset.
Info : esp32.cpu0: Target halted, PC=0x400E9232, debug_reason=00000000
Info : esp32.cpu1: Target halted, PC=0x400D0C7F, debug_reason=00000001
Info : esp32.cpu0: Debug controller was reset.
Info : esp32.cpu0: Core was reset.
Info : esp32.cpu1: Debug controller was reset.
Info : esp32.cpu1: Core was reset.
Warn : esp32.cpu1: target not halted
Info : target esp32.cpu1 was not halted when step was requested
esp32.cpu1: target not halted
target esp32.cpu1 was not halted when step was requested

Hm. Not sure why that happens. Does this occur with a blinky sketch too? Other than generic tips like this and stuff from the general quirks page I don’t know. If no other breakpoints are set in the code (due to number of breakpoints limitations), stepping through the code should work.

Maybe it’s also a power supply issue? Does this occur when the Feather is plugged in via USB to get it’s power from there (and the jumper on the ESP-Prog for power is removed before that)?

The test I’m running is basically a blink sketch with serial printf. I went back to my original configuration with the USB on the Feather plugged into the computer and the ESP-Prog plugged in only when I wanted to start debugging. That still works fine and the upload is fast. It takes a minute or so to completely enter Debug, but that’s documented. It’s not really a problem to use 2 USB ports, but it would be nice if I didn’t have to unplug during upload.

Hi,
I don’t know if it is still helpful, but I had the same issue today. I solved it by reinstalling the driver using ZADIG for both interfaces of the esp-prog.
Somehow the driver setup got corrupted.
After that the upload worked again with both devices connected.