Anyone managed to get debugging working with IDF 4.1 / VS Code / Windows

[espdorian]

I am trying to get debugging working, but wonder if I am looking to a S/W issue or a hardware problem.

Using: Espressif JTAG adapter / LyraT board with WROVER-B

Open OCD starts and detects the device:

Open On-Chip Debugger v0.10.0-esp32-20191114 (2019-11-14-14:19)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
none separate
adapter speed: 1000 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.
Info : Configured 2 cores
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Error: type 'esp32' is missing virt2phys
Info : clock speed 1000 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

While it was not working in VS Code (and the output in the debug window a chunk of unreadable JSON) I tried it from the commandline. The results were similar:

GNU gdb (crosstool-NG esp-2020r2) 8.1.0.20180627-git
....
This GDB was configured as "--host=x86_64-host_w64-mingw32 --target=xtensa-esp32-elf".
....
Reading symbols from blink.elf...done.
(gdb) target extended-remote localhost:3333
Remote debugging using localhost:3333
Ignoring packet error, continuing...
warning: unrecognized item "timeout" in "qSupported" response
Ignoring packet error, continuing...
Remote replied unexpectedly to 'vMustReplyEmpty': timeout

Already reduced the clock rate to 1MHz but it had no effect.

[OllieK]

I do share your frustration. After browsing and evaluating the configuration files in openocd-esp32, reading all found web pages and watching all available videos about ESP, VS Code, and openocd, I was not able to get rid of the error messages. Now I have switched over to Eclipse. In practice, it suits my taste better after using STM32CubeIDE for STM32xxx development (based on Eclipse) for a quite long time. For several years, the ST-Link (SWD) has served me quite well and I am expecting the ESP-Progv(JTAG) to do the same. So far, Eclipse IDE 2020-12 looks very promising.

The first encounters with an older version of Eclipse and Java 11/15 issues were discouraging.

After Arduino IDE, I did use Platformio for development and debugging. The ESP-Prog did work OK with Platformio, but I didn't like the Arduino platform underneath.

[OllieK]

After one additional day with Eclipse 2020-12, the debugging is not working for me. I did try the different Eclipse variants. The embedded version was a disappointment because I could not even select the communication port or the target board. The normal version did work in that frontier. For debugging I did try the Espressif OpenOCD and the generic GDB. I wasn't able to get either of them to work. I am aware that Espressif is saying that the Eclipse 2020-12 is not yet supported by IDF 4.1. Perhaps, I need to wait for that support and try again after that.

At the moment, that leaves the Platformio as the only platform where ESP32 debugging is working for me. To avoid the Arduino libraries, I am now enabling only the IDF based Espressif IoT Development Framework. The debugging did require only the following configuration line

Code: Select all

     debug_tool = esp-prog

in platformio.ini. Compared to the other two IDF alternatives (ESP-IDF Visual Studio Code Extension and Eclipse), the debugging with Platformio is really easy, although it is very slow. The Eclipse for STM32xx families using STLink is much faster.

Be aware that some of the Platformio IDF examples are still using Arduino libraries. This requires some extra effort to fix the examples. For new users learning the rich set of IDF libraries, would require a lot of high quality examples.

Coming from STM32xx world, I have been spoiled by the SVD definitions to allow easy and comprehensive access to peripheral device registers during debugging. The Platformio PERIPHERALS view is very rudimentary compared to STM32xx IDE tools. Perhaps, Espressif could address that issue.

[espdorian]

@OllieK Thenks for your extensive reply. I thought I was the only one, but it seems not. Since I was unable to get simple command line openOCD and GDB even talking to each other, it gave me the impression it has never been used with Windows. (As far as I understand from some posts Eclipse is using MSYS under the hood, which in fact is kind of Linux environment)

Frankly speaking I never liked Eclipse, too slow, too complex and too bulky. I considered to try it, just to see if I could get a working ESP debug setup as reference. Platform I/O is also not my favorite, It pulls in many dependencies and does too many things "under water" which might make projects obfuscated and uncontrollable (and based on experience, sometimes hard to rebuild after updates)
My favourite IDE is Qt creator. Although it was easy to use Qt creator for editing/compiling, it expects a GDB compiled with Python, which was not the case for the Espressif GDB. Since I did not want to compile GDB from sources (just introducing other uncertainties) I abandoned that route and moved to VsCode, which also is a dead end until now.

To be continued.. although IDF is generally is nice and well documented, debugging and Windows seem to be no friends
There is some room for improvement.

[OllieK]

There is light at the end of the tunnel. IDF extension for VSCode/Windows works with the debugger using ESP-Prog interface.

My guess is that the secret for the success was in upgrading the ESP IDF VSCode Extension to Release v0.6.0. At the same time I did upgrade to ESP IDF 4.2 to get full support for my ESP32-S2 boards. Here are the VSC components

Version: 1.52.1 (system setup)
Commit: ea3859d4ba2f3e577a159bc91e3074c5d85c0523
Date: 2020-12-16T16:34:46.910Z
Electron: 9.3.5
Chrome: 83.0.4103.122
Node.js: 12.14.1
V8: 8.3.110.13-electron.0
OS: Windows_NT x64 10.0.19041

At the same time I did observe that the debugger is much faster with IDF Extension compared to Platformio.

Thanks Espressif (and Microsoft).

[espdorian]

@OllieK Good to hear you got it working.
You mentioned "using ESP-Prog interface" Where and how do you configure this ?

From the IDF extension page I know "Use our ESP-IDF Debug Adapter" which is unclear to me what it does. It refers to a debug port: "debugPort: Port for ESP-IDF Debug Adapter. Default: 43474" while in the example launch.json port 9998 is used.
And my ESP debug adapter has a USB/UART connection, no TCP port. So how does this work than ?

Both ports mentioned here are no known ports from openOCD, so is there something else loaded under water ?

I think I miss some background information, it would be nice if your could share your configuration.

[OllieK]

@espdorian,

I have been using the ESP-Prog for my debugging. The only special software installation was the FT2232HL driver. With Platformio,I was able to use both the JTAG and UART through ESP-Prog at the same time. To simplify my debugger testing with VSC, I focused on JTAG and left the UART out. In that testing, I did power the target ESP through the UART line.

In the second step, I did some rewiring and connected the 5V USB power through the JTAG cable. That was not required because the target ESP had its own USB cable. Then the disaster happened when I got careless and the holy smoke took my ESP-Prog. The first detected symptom was that I was not able to flash the target ESP when the JTAG cable was connected.

I had already done several attempts in VSC DBG and OpenOCD frontiers without success. The only major change I did was the installation of IDF Extension 0.6.0 and the debugger did start to work. My next investigation target was SVD, but I was not able to complete that before the disaster. In that sense, I cannot confirm what the real required preparation steps were.

On next week I will get a plain vanilla FT2232HL board for the debugging interface. Perhaps I will not purchase a new ESP-Prog. I already have over 20 STInk2 and 10 STlink3 modules. Some of them are cutoffs from Nucleo boards. I hope that with the FT2232HL chip, I could build something as compact as the STlink3. With the new S2 and S3 boards and chips, I need more debugging tools for the ESP platform

[espdorian]

@OllieK Just to be sure.
You did not use the Zadig tool te remove a VCP driver (required for openOCD) just installed the official FTDI FT2232HL driver ?

After updating the VScode plugin you did not change anything in "launch.json", the default just works ?

Regards,

[OllieK]

I know by sure, that I only installed the FT2232HL drivers with Zadic but didn't remove the VCP driver. With the old VSC Extension version 0.5.x, I did modify the launch.jason during my testing. I know that I did reinstall VSC to get it into known state. I am not sure, if I did modify the launch.jason before the ESP-Prog started to work with VSC Extension.

My next debugging tests will be with the CJMCU-2232HL breakout board. I have not yet done the tracing of the JTAG signals, but that should be easy.

Are you using ESP-Prog or something fancier? What is your target system? I have done most of my testing with Pico D4. Once that will work, I will continue with ESP32-S2-DevKitM-1.

In the next step, I could go with a single channel FT2232 and leave out the UART connection.

[OllieK]

With the FT2232HL board, I can confirm that the debugging works with IDF 4.1 using VSC Extension.

I was not able to confirm, what went wrong with the ESP-Prog board, but there was no way that I could flash the program into ESP32 Pico D4 when it was connected.

Now the next challenge is to install IDF 4.2 and repeat the debugging tests with ESP32-S2-DevKitM-1. There the obstacle seems to be the installation of IDF 4.2. I have not been able to do that without error messages, such as

Code: Select all

  error: command 'C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\BuildTools\\VC\\Tools\\MSVC\\14.28.29333\\bin\\HostX86\\x64\\cl.exe' failed with exit code 2
  ----------------------------------------
  ERROR: Failed building wheel for gevent
ERROR: Could not build wheels for gevent which use PEP 517 and cannot be installed directly