[Solved?] Cannot connect to ESP32-C3 USB/JTAG outside of bootloader

[Charles-S]

Hello.

I'm having a problem that involves several specifics that make it hard to judge where on Earth I should ask for help. If you'll let me explain here, it will help to direct me where to take it from there.

Basically, I have a problem debugging the ESP32 c3 over the inbuilt USB/JTAG from within eclipse-cdt + ESP-IDF plugin.

Specifically, I can erase/flash/verify, as well as connect and run OpenOCD with all the single stepping goodness just fine . . . *IF* and *ONLY IF* I place my dev board into bootloader mode. (ground IO9 while booting) If I place the dev board into user program mode, I can't get OpenOCD to connect to the chip. I get "connection refused" if I try. This alone would not be a problem, except in my IDE the source trace for the debug session *CORRECTLY* follows along that we are in the bootloader code segment, and not the user code. In other words, sure I can single step... but only the bootloader code, and not my program. The solution is obvious, exit the boot loader.... but therein lies the exact problem... I can't get into debugging from the start if I'm not starting from the boot loader. Catch 22

... seems like it should be as simple as flash -> verify -> jump to user code... and there are setting to this effect under the "start" tab of launch configuration... but it's not working.

... where go? ... what do?

[ESP_Sprite]

For now, this forum is fine, we can always move it when needed. (But note I edited your title to more accurately reflect the issue you're having)

Are you sure that your program doesn't reinitialize GPIO18/GPIO19? That would break the USB connection leading to all sorts of errors.

[Charles-S]

Are you sure that your program doesn't reinitialize GPIO18/GPIO19? That would break the USB connection leading to all sorts of errors.

This was my initial guess. In fact, I remember that being a problem for me previously too.

However, no, these are virgin chips straight from the distributor with no user code, just bootloader, and they won't debug from user mode. Furthermore, at least one of programs I'm flashing is the "hello world" example, which *SHOULDN'T* mess with GPIO18/GPIO19, at least not directly. My only concern is that the example program *DOES* send stuff to stdio, which *COULD* be directed to the UART that is part of the embedded debug hardware. The serial monitor? ... I'm pretty sure OpenOCD/GDB needs that to be unmolested to work.

Anyway, that was my other thought. Thank you for your guidance. I'll see if I can't burn in some more example/defaults, being particular to make sure they do nothing that could mess with GPIO18/GPIO19, or the serial monitor hardware. If I figure something new out, I'll report back.

[ESP_Sprite]

No, the JTAG and the serial functionality of the USB-serial-JTAG converter are two entirely separate channels; I don't know of a way in which messing with only the serial port functionality would affect JTAG.

Maybe one more thing to try: if you're using ESP-IDF, can you select the USB-serial-JTAG as the main console (not the aux one), reflash and try again?

[Charles-S]

Negative my friend. Same result. Here is the output.

Code: Select all

Open On-Chip Debugger v0.11.0-esp32-20221026 (2022-10-26-14:48)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
Info : esp_usb_jtag: VID set to 0x303a and PID to 0x1001
Info : esp_usb_jtag: capabilities descriptor set to 0x2000
Warn : Transport "jtag" was already selected
Flashing C:/Users/<user>/eclipse-workspace/hello_world/build/bootloader/bootloader.bin at 0x0
Error: libusb_open() failed with LIBUSB_ERROR_NOT_SUPPORTED
Info : esp_usb_jtag: serial (68:67:25:54:3E:38)
Info : esp_usb_jtag: Device found. Base speed 40000KHz, div range 1 to 255
Info : clock speed 40000 kHz
Info : JTAG tap: esp32c3.cpu tap/device found: 0x00005c25 (mfg: 0x612 (Espressif Systems), part: 0x0005, ver: 0x0)
Info : datacount=2 progbufsize=16
Info : Examined RISC-V core; found 1 harts
Info :  hart 0: XLEN=32, misa=0x40101104
Info : starting gdb server for esp32c3 on 3333
Info : Listening on port 3333 for gdb connections
Info : JTAG tap: esp32c3.cpu tap/device found: 0x00005c25 (mfg: 0x612 (Espressif Systems), part: 0x0005, ver: 0x0)
Info : Reset cause (3) - (Software core reset)
Info : [esp32c3] Found 8 triggers
Error: Failed to get flash maps (4294967295)!
Warn : Failed to get flash mappings (-4)!
Error: Failed to get flash size!
Error: Failed to get flash size!
Error: Failed to probe flash, size 0 KB
Error: auto_probe failed
Error: Failed to find bank 'esp32c3.flash'!
** Flashing Failed **
-1
Started by GNU MCU Eclipse
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : accepting 'gdb' connection on tcp/3333
Warn : No symbols for FreeRTOS!
Error: Failed to get flash maps (4294967295)!
Warn : Failed to get flash mappings (-4)!
Error: Failed to get flash size!
Error: Failed to get flash size!
Error: Failed to probe flash, size 0 KB
Error: auto_probe failed
Error: Connect failed. Consider setting up a gdb-attach event for the target to prepare target for GDB connect, or use 'gdb_memory_map disable'.
Error: attempted 'gdb' connection rejected
shutdown command invoked

The error says set memory map disabled, but in my launch configuration I have

Code: Select all

set mem inaccessible-by-default off

command line switches. . . or is that something else? (Is now Googling it . . .)

[Charles-S]

So... it is, in fact, attaching to the device while in user mode. Otherwise it wouldn't say

Code: Select all

JTAG tap: esp32c3.cpu tap/device found: 0x00005c25 (mfg: 0x612 (Espressif Systems), part: 0x0005, ver: 0x0)

How else could OpenOCD know what it's attached to?

But it's also saying the dreaded libusb errors... the driver is correct though... I mean how else could it flash when in bootloader mode.

... hummmm

(sorry, kinda just thinking out loud/as I go)

[Charles-S]

More info:

When I successfully launch debug via bootloader mode, the debug window does indeed show 'hello_world.elf' as the program being debugged. And, under the executable tab, there is a separate entry for 'bootloader.elf', and 'hello_world.elf'. So it would appear on the surface at least that eclipse believes it is debugging the user executable, even when debugging from bootloader mode. This would make perfect sense, if, after flashing, the bootloader was instructed to exit then jump to user code, which I would expect to be the norm.

The problem, or, rather... a new problem... when I click on 'hello_world.elf, I suddenly get an error that says eclipse can't load the debug symbols for the program... !!?

Code: Select all

An internal error occurred during: "Reading Debug Symbol Information: hello_world.elf".

To make sure I'm not crazy or stupid as all get out, (still debatable) I went through SDK config>compiler options and made certain that I was building my user code in debug mode... (Compiler flag -Og)

Highly odd that I would not have debug symbols for a program I JUST built. Odd that I don't get this as an error until I click on that particular section of the IDE.

...

Maybe not having debug symbols is the only problem, and I was getting into user code from the bootloader all along? That still doesn't answer the (somewhat silly) question of why I can't enter program/debug without the board being in program/debug mode, but... I'm fine with that TBQH, I just need to be able to debug user code... don't much care how I get there.

So, really I guess, I just need to know why my debug symbols are getting lost...? :/

[Charles-S]

No, the JTAG and the serial functionality of the USB-serial-JTAG converter are two entirely separate channels; I don't know of a way in which messing with only the serial port functionality would affect JTAG.

Ah yes, I forgot to mention... (and sorry for spamming)

The official documentation ties the serial port into programing, which is tied into debugging. The relevant part is here. This is why I assumed that messing with the serial port would mangle the process. The serial port is needed by esptool.py for flashing.

[Charles-S]

Another update:

I've done a few more tests, and learned some things. Most importantly, I've attached an LED to GPIO4 for running the blink example and watching actual, tangible, physical reaction of the chip itself.

When loading the blink example in bootloader mode, I can confirm that, in fact, the debugging session *IS NOT* running under user code, in spite of what my IDE might say. I figure this because hitting the run button in the debugging session does not let the LED do the blink cycle per user algo. The LED stays as it would while in bootloader mode. However, after I flash the user program then power cycle, the LED blinks as expected.

Secondly, I've tried to launch the debugger while in user mode, and noted that it does actually halt/freeze the chip, confirming that it is in fact punching through user code into the hardware debugger.

I noted that GDB uses a tcp port to host/serve the GDB<->OpenOCD communication, and randomly had an epiphany! "What's Windows firewall doing to that?" And so, I went into Windows firewall settings and temporarily shut it off.... There was no effect.

The first error I get is still this...

Code: Select all

Error: Failed to get flash maps (4294967295)!

...Which seems to be related to an actual bug in OpenOCD for ESP-IDF. I've tried manually using different versions to see if that changes anything. I still get "target disconnected" errors.

I'm on ESP-IDF v5R now. Have had this working before... really wish I knew which version. Going to revert back through some of the older versions and see if that fixes anything.

(Sorry 2.0 for, once again, spamming the thread.)

[Charles-S]

YAY!!!!! I got something that looks like success!!!!

So... as per the error, and as per this git hub issue, if you simply add the following command to the OpenOCD config options, via launch configuration... it suddenly all "just works."

Code: Select all

-c "gdb_memory_map disable"

To be clear, for any one seeing this or similar problems under eclipse. After you load an example program, click the launch configuration drop down box (the center one) click "New Launch Configuration" make sure you have the little bug selected, then click on "ESP-IDF GDB OpenOCD Debugging" Click next. Assuming you have downloaded, installed, and configured ESP-IDF correctly, ALMOST EVERYTHING should be populated correctly across all tabs. The only thing you should have to change from the default is (1) change "Board" to "builtin USB-JTAG" and then (2) add the above command into the box below. This is all on the "Debugger" tab, BTW. My final OpenOCD command looks like this...

Code: Select all

-s ${openocd_path}/share/openocd/scripts -f board/esp32c3-builtin.cfg -c "gdb_memory_map disable"

If this proves to be the full and complete solution, I would recommend that it be brought to the attention of whoever writes "esp32c3-builtin.cfg" as this command could/should be integrated there.