Espressif ESP32-H2 JTAG Debugging

[gojimmypi]

Greetings –

I’ve been using VisualGDB to successfully JTAG debug all of the currently-supported ESP-IDF v5.1 targets with the exception of the ESP32-H2.

I see in this thread that the ESP32H2 was supported in VisualGDB starting with EDP-IDF v5.0.

I’ve tried this on two different, genuine Espressif ESP32-H2 dev kits: one that I bought from Mouser last summer and most recently this ESP32-H2-DevKitM-1-N4  from Amazon.

When I press the “test” button on the “Debug Settings” of the “VisualGDB Project Properties”, the device is immediately found, but then gets stuck after “Warn : No symbols for FreeRTOS!” (see attached log file).

I’ve tried various speed settings, different cables, different Windows drivers (via Zadig), I even tried hooking up my known-to-work Tigard JTAG board that curiously encountered the same problem.

I’m not sure if this is a VisualGDB issue or perhaps something unusual with the ESP32-H2 USB port.

Has anyone been able to single-step code on an ESP32-H2?

I’m using Visual Studio Enterprise 2022 17.7.6 and VisualGDB 5.6. Here is the VisualGDB project file that I’m using.

Thanks for taking a look.

Jim

 

Attachments:

You must be logged in to view attached files.

[support]

Hi,

It really looks like something between the Espressif’s OpenOCD port and the chip. We are not affiliated with Espressif and do not have insights into their chips or tools beyond their official documentation.

If you suspect VisualGDB is using OpenOCD incorrectly, you can always try running the binaries from Espressif manually. If they also don’t work, please contact Espressif for further help. If they do work, please try comparing the command lines between the working and broken setup. If you can point out a specific difference causing the issue, we can gladly investigate it further.

That said, we have recently updated our OpenOCD package to match the latest release from Espressif. Please try installing it via VisualGDB Package Manager. It may contain a fix for this specific issue.

[gojimmypi]

Hello,

I recently installed the 20231123 ESP32 Debug Methods update to VisualGDB.

The JTAG programming and debugging capabilities (ESP-IDF v5.1) seem to be working well for the ESP32-H2 now! Thank you.

There is however an oddity when pressing the “Debug – Test” button, indicating that the test failed:

Error: Error on socket 'GDB': WSAGetLastError==10054, message: An existing connection was forcibly closed by the remote host.

I’ve attached the full log for reference. So far, it seems the error can be ignored.

Also, note that unlike other devices when doing idf.py erase-flash , the ESP32-H2 is not in a happy state when freshly erased. Error “invalid header” scrolling endlessly. In this state I am unable to JTAG debug.

Here’s an example of the console output after erase & JTAG will not work:

invalid header: 0xffffffff
invalid header: 0xfffff▒ESP-ROM:esp32h2-20221101
Build:Nov 1 2022
rst:0x7 (TG0_WDT_HPSYS),boot:0xc (SPI_FAST_FLASH_BOOT)
Saved PC:0x40011bdc
invalid header: 0xffffffff
invalid header: 0xffffffff

Upon flashing a clean, operational “hello world” (or any other app) – then the JTAG capabilities work fine.

Thank you again for this fix.

Cheers

Attachments:

You must be logged in to view attached files.

[support]

We have just rechecked the settings testing GUI. OpenOCD indeed shows the “Error on socket” message (because VisualGDB closes the socket abruptly after confirming that it works) , but VisualGDB still shows the correct “Connection test succeeded” message. If you actually get an error message box instead, please feel free to attach a screenshot and we will investigate.

As for idf.py erase-flash, it is really something to check with Espressif. The idf.py file and all logic inside it comes from them. We don’t touch it, we don’t run any comprehensive tests on it beyond checking for unsatisfied dependencies, and rely on Espressif to fix issues in it.

You can try installing ESP-IDF 5.2 into the IDF 5.1 toolchain via the first page of VisualGDB Project Properties. Based on some quick tests, it is compatible with that toolchain, and might include some additional fixes.

[Author]

Posts