Connection timed out when trying to debug.

[Gardin]

Hello guys,

I recently bought an esp-prog board and now I'm tryng to use it, but I'm failing to do so using esp-idf.

I can debug without any problem using platformio, so I know everything works and my connections are right, but when I try to do it natively under eclipse or in the terminal I only get:

Code: Select all

:3333: Connection timed out.

I've follow this link: https://docs.espressif.com/projects/esp ... ugger.html

I'm using esp-idf version: v4.1-dev-2055-gf5b82c5b1

Does anyone have a hint?

thanks,

Gardin.

[Gardin]

I figured it out.

Before starting the GDB debugging in eclipse I have to enter these command in the project directory:

Code: Select all

openocd -f board/esp32-wrover-kit-3.3v.cfg

And then with openocd running I can start debugging as described in the espressif tutorial.

[RLB_Sr]

@Gardin Thanks, that was helpful.

[rowsail]

Thank you Gardin. You would not believe the man-weeks we have wasted on the how fragile the IDE system. It doesn't seem to matter which IDE we have used: Eclipse, Espressif-IDE, PlatformIO, VSCode - the system will work fine for a few days and then simply stop communicating with the debugger. It has got to the point where we would run [idf.py flash] from the command line, and then start the debugger to attach to a running system. This worked OK up until the last few hours (which I've wasted trying various power cycles, resets, rebuilds etc.) In 30+ years of development I have never used such a terrible set of tools. Are we not seeing more reports of this because very few use the IDF - and use Arduino instead?

Yet for all the wasted days/weeks the fix was running openocd from the command line - sweet! In my case I was using an ESP32S3 with the internal USB/JTAG interface, so for anyone else having the same issues the command (having done all the regular stuff to set up the environment variables:

Code: [Select all] [Expand/Collapse]

1. . ./export.sh

GeSHi © Codebox Plus Extension

was

Code: [Select all] [Expand/Collapse]

1. openocd -f board/esp32s3-builtin.cfg

GeSHi © Codebox Plus Extension

Now this is of course a workaround to the current fragility, so if anyone has a much better fix, which perhaps includes reflashing the code instead of having to use the command line tools, that would be very much welcomed! (If I fix it myself I'll post the solution here - I can't be only us with the issues.)

[rowsail]

Might have spoken too soon. After entering the openocd - f... (which got the system talking again), it then failed again and I hav enot been able to recover it yet. What might be of interest is that running openocd from the command line makes it clear what error messages are being thrown:

Info : accepting 'gdb' connection on tcp/3333
Error: attempted 'gdb' connection rejected
Info : accepting 'telnet' connection on tcp/4444
Info : dropped 'telnet' connection
Info : accepting 'tcl' connection on tcp/6666
Info : dropped 'tcl' connection
Error: libusb_bulk_write error: LIBUSB_ERROR_NO_DEVICE
Info : esp_usb_jtag: serial (80:65:99:C5:4D:04)
Info : esp_usb_jtag: Device found. Base speed 40000KHz, div range 1 to 255
Error: missing data from bitq interface
Polling target esp32s3.cpu0 failed, trying to reexamine
Error: libusb_bulk_write error: LIBUSB_ERROR_IO
Error: libusb_bulk_write error: LIBUSB_ERROR_IO
Error: libusb_bulk_write error: LIBUSB_ERROR_IO
Error: libusb_bulk_write error: LIBUSB_ERROR_IO
Error: missing data from bitq interface
Polling target esp32s3.cpu1 failed, trying to reexamine
Error: extra data from bitq interface
Examination failed, GDB will be halted. Polling again in 100ms
Error: libusb_bulk_read error: LIBUSB_ERROR_IO
Error: libusb_bulk_read error: LIBUSB_ERROR_NO_DEVICE
Error: libusb_bulk_read error: LIBUSB_ERROR_NO_DEVICE

It would appear that openocd is happily talking to the ESP32 via the jtag interface, but on attempting to connect from the IDE/debugger, the connection is dropped, and various LIBUSB errors generated.

[ccrause]

To see more debug information add -d to the openocd command line. Hopefully the cause will be revealed in the more information dense output.