Sparkfun ESP32-S3 Thing Plus - JTAG?

Development Boards ESP32
1

Can I use the built-in JTAG interface of the ESP32-S3 through the USB C connector on the Sparkfun ESP32-S3 Thing Plus, or do I need some additional kit or setup first?

If I need additional kit or setup, the rest of my post can probably be ignored, but any information for setting this up would be much appreciated!

Background

I’m an experienced programmer but relatively new to microcontrollers. I’d like to be able to set breakpoints and step through my code in ESP-IDF to ease the pain of debugging.

I created a new project using ESP-IDF v5.5.1, selected esp32s3 as the ESP-IDF Target, and ESP32-S3 chip (via builtin USB-JTAG) as the ESP-IDF board. I used the blink example to keep things simple. After building the project, if I try to flash it using the JTAG method then OpenOCD exits with the errors Error: libusb_open() failed with LIBUSB_ERROR_NOT_FOUND and Error: esp_usb_jtag: could not find or open device!. I see the same errors if I run the command openocd -f board/esp32s3-builtin.cfg.

What I’ve Found Elsewhere and Tried

Documentation:

  • The Espressif documentation states “Only a USB cable connected to the D+/D- pins is necessary” and says that the USB D-/D+ signals are on GPIO19 and GPIO20.
  • The Sparkfun ESP32-S3 Thing Plus datasheet states that pins 23 and 24 are GPIO19/USB_D- and GPIO20/USB_D+ respectively (page 11).
  • Page 28 of the datasheet shows pins 23 and 24 connected to the USB OTG connector, although it does also show pins 35-38 connect to a JTAG interface. As far as I can tell, those pins aren’t broken out on the board so I wouldn’t be able to access them anyway.
  • Page 15 (section 3.3.4) of the datasheet talks about GPIO3 and eFuses to control the source of JTAG signals during the early boot process. The table there suggests that the JTAG controller should work if the 3 eFuses are set to 0. I checked in the ESP-IDF eFuse Explorer and these are all 0.

Things I’ve tried:

  • I have verified that the board is in bootloader mode (hold BOOT, press and release RST, then release BOOT).
  • Verified that my computer can see the JTAG interface - USBDeview shows a device with VID 0x303a and PID 0x1001 described as USB JTAG/serial debug unit. The output from openocd states that it is looking for a device with this VID/PID before it fails.
    • The openocd output does also include the line Info: esp_usb_jtag: capabilities descriptor set to 0x2000, whereas USBDeview shows a blank Capabilities field for the device. I’m not sure if this is preventing openocd from detecting the device.
  • I used USBDeview to verify that the driver for the JTAG device is WinUsb.sys.
  • I have installed the Espressif - WinUSB support for JTAG (ESP32-C3/S3) driver as instructed in the Espressif documentation where it states that “Windows users might get LIBUSB_ERROR_NOT_FOUND errors” and suggests installing this driver.
  • Lastly, some sources I’ve found say to check that the USB C cable is connected to the correct USB port. There is only one USB port on the board I have.

Any suggestions as to how I might get this up and running would be much appreciated, thanks!

2

Yes, D- and D+ (D19 & D20) are used for the usb data

This is a windows driver config error, you’ll need to point it to use interface 2 (instead of the likely default 0) using Zadig ; see Kimi | ESP32-S3 USB-JTAG Setup

3

I was hoping to come across someone more experienced or with a better understanding by posting here. The low-effort LLM vomit response wasn’t helpful at all. I had already found all of that information through my own research.

  • Zadig said the driver for USB JTAG/serial debug unit (Interface 2) was already WINUSB
  • Device Manager showed APP Mode and USB JTAG/serial debug unit devices.
  • The idf-env tool stated that the driver was already installed.
  • The cable is a data cable (verified by using the Monitor Device command in ESP-IDF which is able to monitor serial output from the device).
  • I had restarted my computer after installing the Espressif driver.

Fortunately I have now managed to resolve the issue myself. The tl;dr; for anyone who might come here after is:

  1. Open device manager, expand Universal Serial Bus devices, then right-click and uninstall USB JTAG/serial debug unit.
  2. Disconnect and reconnect the device.
  3. To verify whether the correct driver is now active, right-click USB JTAG/serial debug unit again in device manager and select Properties.
  4. Click on the Driver tab and verify that the Digital Signer field mentions Espressif Systems
  5. Delete your LLMs before your brains rot entirely.

How did I get here? Well, the complete error messages output by the openocd -f board/esp32s3-builtin.cfg were as follows:

Error: 937 3212 libusb_helper.c:279 jtag_libusb_open(): libusb_open() failed with LIBUSB_ERROR_NOT_FOUND
Error: 938 3215 esp_usb_jtag.c:636 esp_usb_jtag_init(): esp_usb_jtag: could not find or open device!

I found the code for the jtag_libusb_open() function on GitHub here. The error occurs on line 176 and is output on line 179. It didn’t look like anything could go wrong there but I downloaded libusb and compiled a sample application to verify this myself (basically just copying the jtag_libusb_open() function with additional debug logging). The libusb_get_device_list() function did return a device with the correct VID/PID (0x303a/0x1001), but the call to libusb_open() failed with the return code LIBUSB_ERROR_NOT_FOUND, indicating that the device was not found despite it having being enumerated/returned by libusb.

Based on this, the issue/bug was clearly in libusb and not any of the higher level components. A search for libusb Windows LIBUSB_ERROR_NOT_FOUND led to various GitHub issues and eventually this comment. No LLMs involved, just some actual intelligence. Amazing.

4

While I can appreciate the impetus behind this attempted chiding, it is far less helpful to focus on what didn’t work at all…we sell MCUs and sensors that rely on myriad libraries/projects that we generally will only have superficial knowledge of…we are equipped to assist customers with the controllable aspects thereof. If you’re expecting us to know everything about everything off-hand…we uh, don’t.

What was suggested works for 90%+ of users, but there are always quirks across all OS with OS update vs driver updates vs pointers vs security vs hardware vs etc. The idf-env tool should have installed the Espressif-signed driver, but it apparently didn’t work properly in this case (or needed the manual reinstall to force refresh windows’ driver cache)

It is absolutely wild to ask for help, bash it, then link a workaround that is nearly identical to what was suggested by the LLM…from the thread you’ve linked:

" > OK, I can install the WinUSB driver through zadig, instead of espressif’s installer. This is an acceptable workaround. For those coming across this in the future, be sure that your drivers look like this:

Device 1: USB Serial image This device will remain as the default windows usbser driver, we shouldn’t change it.

Device 2: Regular USB image note that if it shows its signed by espressif instead of libwdi, thats fine, it means the espressif installer worked and you don’t need zadig.

This second device is the one that needs to be installed with Zadig. I used WinUSB as the driver. Be sure you select “install driver” instead of “install WCID driver” in the dropdown. It should look like this: image

I can confirm this worked for my ESP32-S3 as well, on Windows 10."

That seems an awful lot like what was suggested? Anyhow, there really isn’t any need to insult anyone or anything on these forums. Also note that heeding ‘A search for libusb Windows LIBUSB_ERROR_NOT_FOUND led to various GitHub issues and eventually this comment. No LLMs involved, just some actual intelligence. Amazing.’ is befuddling…you’ll find humans are often wrong too :wink: Also weird to piggyback on someone’s else’s post and call your method ‘intelligence’

Finally, I’ll summarize the thread with a TL;DR:

If Zadig shows WinUSB is already installed but OpenOCD still fails with LIBUSB_ERROR_NOT_FOUND , try manually reinstalling the driver via Device Manager to ensure you get the ‘Espressif Systems’ signed driver specifically, rather than a generic WinUSB driver

Be good out there, glad to hear it’s working.

5

Bless you. Of course I never expected anyone to know everything. I posted on a community forum hoping to find someone more experienced who has run into the same issue and tried all the same things that are easily found with Google or maybe some LLM; or someone more knowledgeable who can help diagnose the issue further than those discussions that are easily found with Google. Maybe someone who has a better idea of what to Google i.e. it’s a libusb issue not an ESP-IDF or ESP32-S3 Thing Plus issue. It’s easy to find information when you know what you’re looking for.

I didn’t expect to be given the virtual finger, by an employee no less, with a low-effort LLM response regurgitating the information that’s readily available through Google, that I’d already trawled through.

As for the solution, well, the devil is in the detail. The detail your lazy LLM response missed. The detail that’s difficult to find if you’re unsure what you’re searching for. The detail that I added here.

Maybe don’t give the virtual finger with a low-effort LLM response next time. If you don’t know, you don’t know. That’s ok. You don’t have to write something. You don’t have to say something.

6

Save the senseless animosity and especially blessings! Nothing here is personal (but if it were I’d have quite a few suggestions). We’re here to help.

Let’s address a couple things. “Maybe don’t give the virtual finger with a low-effort LLM response next time. If you don’t know, you don’t know. That’s ok. You don’t have to write something. You don’t have to say something.” Do you think it honestly would’ve been more useful to leave the thread hanging? It is literally my job to ‘have to write something’ lol; I am quite regularly at the limits of my knowledge and rely on manifold sources of info. While LLMs can be error-prone, I vet the logic, workflow, links, as viable beforehand. Worth noting that this AI in particular provides direct citations for its suggestions. I would be providing considerably worse service if I wrote them off wholesale (food for thought!). I will continue to perform my duties as I deem necessitated by such :smiley:

Stanger still, here’s one of the cited instructions/links from my original response:

…where are the missing details? To be clear, it was a windows driver signature error…something that SF does not control whatsoever, but we gave it a shot. Even if you don’t think it helped, it certainly doesn’t harm.

It’s going to get real weird real soon if we are obstinate regarding integrating aspects of AI into our workflow(s). The opposite is also true!

7

Absolutely 100% yes it would have been more useful for you to leave the thread alone! You couldn’t have done anything more useful! As for the rest of your reply, you can quit the babbling now. I already posted the solution.

1 Like