ESP32 Forum

Posted: **Fri Nov 18, 2022 3:25 pm**

I'm working on a windows 10 computer using Visual Studio Code 1.73.1, ESP IDF 4.4.2 and OpenOCD 0.11.0. My development board is an ESP32C3 DevkitM-1 V1.0. I've been porting a product to the Espressif system, but I'm at a point where I need to debug some pointer issues and need live debugging. I had yet to get OpenOCD working so I set out to make it work. Since the ESP32C3 has a JTAG system built in I should be able to debug using a USB cable plugged into the dev kit. I have an ESP-PROG board as well, that I have tried plugging into the Correct pins on the ESP32C3 (which is different than just the ESP32) and have not had sucess with that. I have use zadig and tried a couple of different drivers for both the ESP-PROG ftdi chip and for the DevkitM-1 without changing results.

Some of the tutorials that I watched made it sound like OpenOCD came bundled with ESP IDF, but I did not see it. I added it in along side my IDF installation and that seems to be ok. Ultimately I plan on automating the launch of OpenOCD as explained in this tutorial: https://www.youtube.com/watch?v=uq93H7T7cOQ, but right now I am launching OpenOCD from the Powershell terminal from within VSCode. The command that seems the most appropriate for using the built in JTAG is 'openocd -f $OPENOCD_SCRIPTS/board/esp32c3-builtin.cfg'. Here is the output:

Code: Select all

PS C:\projects\Espressif_prj\myLifterESP> openocd -f $OPENOCD_SCRIPTS/board/esp32c3-builtin.cfg   
Open On-Chip Debugger 0.11.0 (2021-11-18) [https://github.com/sysprogs/openocd]
Licensed under GNU GPL v2
libusb1 09e75e98b4d9ea7909e8837b7a3f00dda4589dc3
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
Error: The specified debug interface was not found (esp_usb_jtag)
The following debug adapters are available:
1: ftdi
2: usb_blaster
3: usbprog
4: jlink
5: vsllink
6: rlink
7: ulink
8: arm-jtag-ew
9: hla
10: osbdm
11: opendous
12: aice
13: picoprobe
14: cmsis-dap
15: xds110
16: st-link

'Error: The specified debug interface was not found (esp_usb_jtag)' is my issue. It seems that a debug adapter is missing. I'm not sure if this is hardware (like an incorrect driver so OpenOCD cannot find the hardware) or a chunk of software (to link OpenOCD to the driver). I've dug through the .cfg files and they are there and the files they are dependent on seem to be there. In esp_usb_jtag.cfg line 6 is 'adapter driver esp_usb_jtag' and this happens to be in the interface folder, so it seems to exist to this point.
I've tried searching for the error that I am having, but I have been unable someone else that has had this same error.

I have tried a few other .cfg files and they all fail as well with or without the ESP-PROG board.

What am I missing here to get OpenOCD to play nice with the ES32C3?

Posted: **Sat Nov 19, 2022 1:27 am**

You need an ESP-specific version of OpenOCD as the usb-serial-jtag (and more changes) aren't in the mainline yet. That should be installed with ESP-IDF at the same time the C compiler was downloaded&installed; I don't know exactly where that gets stored under Windows, though.

Posted: **Sat Nov 19, 2022 9:03 am**

Just a note, the usb_serial_jtag driver is available in the upstream OpenOCD (https://github.com/openocd-org/openocd/ ... usb_jtag.c) but it's not in Sysprogs' fork yet.

Indeed, esp-specific OpenOCD build is installed along with esp-idf. It seems that you also have OpenOCD from VisualGDB installed, and that gets launched instead of the one installed by esp-idf. I suggest checking the environment variables defined in VS Code settings. Perhaps the path to VisualGDB copy of OpenOCD is earlier in the path than the IDF copy.

Posted: **Tue Nov 22, 2022 6:47 pm**

Yesterday I applied what I learned yesterday and ran into new issues and solved a few of them.

Yes, esp-idf does contain OpenOCD as it should, but it was in a folder I did not expect and buried quite deep. It may have set it up that way, but that was months ago and I understood nothing about this development environment. I installed stuff in a file alongside my esp-idf installation called SDK. Similar paths for other installations in Windows should apply to other users.

I added an environment variable:
OPENOCD_SCRIPTS = "C:\projects\Espressif_prj\sdk\tools\openocd-esp32\v0.11.0-esp32-20220411\openocd-esp32\share\openocd\scripts".

I also added:
"C:\projects\Espressif_prj\sdk\tools\openocd-esp32\v0.11.0-esp32-20220411\openocd-esp32\bin" and "C:\projects\Espressif_prj\sdk\tools\openocd-esp32\v0.11.0-esp32-20220411\openocd-esp32\share\openocd\scripts" to my path variable.

I'm not sure if I need the all, but I know adding them to path allowed me to run OpenOCD from the command prompt with the simple "openocd -f board/esp32c3-builtin.cfg" command. Alos these path changes required me restarting VSCode before they started to work correctly.

My hardware setup is an ESP32-C3DevkitM-1V1.0 with a USB plugged into the mini USB port and a second USB with the two data lines broken out connecting the header on the board. The green wire goes to pin 19 and the white goes to pin 18. This solved the second issue that came up after getting OpenOCD to run the esp-idf version where it could not find the hardware. Makes sense since it was not plugged in. I was under the assumption that the existing USB already connected to the D+ and D- pins on the board. However the more I read, the more I found references to having two USB ports visible in the device manager. The mini USB shows up as a Silicon Labs CP210x device and the second deice is just a regular COM port. I did have to use the USB Driver Tool https://visualgdb.com/UsbDriverTool/ or Zadig https://github.com/pbatard/libwdi/wiki/Zadig to change the drive to the WinUSB driver.

With the correct driver I could get it connect using this launch.json file:

Code: Select all

{
  "version": "0.2.0",
  "configurations": [
    {
	  "preLaunchTask": "preRun",
      "name": "ESP debug",
      "type": "cppdbg",
      "request": "launch",
      "MIMode": "gdb",
      "miDebuggerPath": "${command:espIdf.getXtensaGdb}",
      "program": "${workspaceFolder}/build/${command:espIdf.getProjectName}.elf",
      "windows": {
        "program": "${workspaceFolder}\\build\\${command:espIdf.getProjectName}.elf"
      },
      "cwd": "${workspaceFolder}",
      "environment": [{ "name": "PATH", "value": "${config:idf.customExtraPaths}" }],
      "setupCommands": [
        { "text": "target remote localhost:3333" },
        { "text": "set remote hardware-watchpoint-limit 2"},
        { "text": "mon reset halt" },
        { "text": "thb app_main" },
        { "text": "flushregs" }
      ],
      "externalConsole": false,
      "logging": {
        "engineLogging": true
      }
    }
  ]
}

//  ESP-IDF Debug Adapter:
// {
//   "version": "0.2.0",
//   "configurations": [
//     {
// 	  "preLaunchTask": "preRun",
// 	  "name": "ESP OpenOCD",
//       "type": "cppdbg",
//       "request": "launch",
// 	  "cwd": "${workspaceFolder}/build",
// 	  "program": "${workspaceFolder}/build/myLifterESP.elf",
// 	  "miDebuggerPath": "C:/projects/Espressif_prj/sdk/tools/riscv32-esp-elf/esp-2021r2-patch3-8.4.0/riscv32-esp-elf/bin/riscv32-esp-elf-gdb.exe",
// 	  "setupCommands": [
// 		{ "text": "target remote 127.0.0.1:3333" },
// 		// { "text": "target remote :3333" },
// 		{ "text": "set remote hardware-watchpoint-limit 2"},
// 		{ "text": "monitor reset halt"},
// 		{ "text": "flushregs"},
// 		// { "test": "mon program_esp build/bootloader.bin 0x1000 verify"},
// 		// { "test": "mon program_esp build/partition_table/partition-table.bin 0x8000 verify"},
// 		// { "test": "mon program_esp build/myLifterESP.bin 0x10000 verify"},
// 		// { "text": "monitor reset halt"},
// 		// { "text": "flushregs"}
// 	  ]
//     }
//   ]
// }

The commented out section is based on the tutorial I referenced in the first post and the active code is mostly what came in the file already. Either one gives me an error with "target remote" and "mon" setup commands. I commented those out and it will run for a second and then quit with the error "ERROR: Unable to start debugging. Unexpected GDB output from command "-exec-run". Don't know how to run. Try "help target"." WIthout commenting out "target remote" I get "and erro message after it tried to run for a few seconds saying "Unable to start debugging. Unexpected GDB output from command "-interpreter-exec console "target remote localhost:3333"". localhost:3333: (undocumented errno 138)."

I think it should run with those lines of code, but I'm not sure where to look next?

I have a preRun task that starts OpenOCD when pressing the debug button that looks like this:

Code: Select all

"tasks": [
		{
			"label": "preRun",
			"type": "shell",
			"windows":{
				"command": [
					"clear",
					"start openocd -c \"set ESP_RTOS none\" -f board/esp32c3-builtin.cfg",
					"exit"
				]
			}
		}

I found this thread that seems to have the same issue, but it has gone unanswered for several months now: https://esp32.com/viewtopic.php?t=27043.

Where do I begin to fix this?

Posted: **Wed Nov 30, 2022 9:51 pm**

I haven't made any progress with the above issue. After trying some other things the button I was using that appeared at the bottom has disappeared and I tried the 'play' button at the bottom and that seem to try to debug differently. But there are some obvious issue where it applies a default target and is using some bad paths.

It is assigning the default ESP32 target in place of the ESP32C3 target. Just building and monitoring compiles fine. When I try to debug it, something about the compile chain of events thinks that the target is not set and it changes it to ESP32. I cannot find the source of truth for this. sdkconfig is not it. Menu config shows no option for specifying a target. Settings.json has "idf.adapterTargetName": "esp32c3", but that is not honored. Where is the source of truth for compiling for debugging?

The output console ends up showing warning messages for not being able to find Xtensa compiler tools. That makes sense since it is setting the project to compile for the ESP32 and not the ESP32C3 like it should.

There is another thing that seems to be off. The output also shows compiler paths that lead to gcc and g++ compilers that I do not want. I have gotten rid of these from path (I think they were there when I was working on a Zephyr project) but now with the paths gone, they still show up. I don't know where the source of truth for these are as well. I've tried reinstalling and installing a new instance of ESP-IDF with the same result. Here is an output snippet:

Code: Select all

[proc] The command: "C:\Program Files\CMake\bin\cmake.EXE" --no-warn-unused-cli -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=TRUE -DCMAKE_BUILD_TYPE:STRING=Debug "-DCMAKE_C_COMPILER:FILEPATH=C:\Program Files\Haskell Platform\8.4.3\mingw\bin\gcc.exe" "-DCMAKE_CXX_COMPILER:FILEPATH=C:\Program Files\Haskell Platform\8.4.3\mingw\bin\g++.exe" -Sc:/projects/Espressif_prj/myLifterESP -Bc:/projects/Espressif_prj/myLifterESP/build -G Ninja exited with code: 1 and signal: null

How can I change it's mind?

"C:\Program Files\Haskell Platform\8.4.3\mingw\bin\gcc.exe" should be pointing to a gcc.exe file in ESP-IDF. This occurs when I try to debug, but not when I build and program and monitor. It is correct when I build. It's only because of the building done when I am debugging. That scripting seems to be setup separately. Where can I go to fix this?

CMakcCache.txt changes depending upon if I build or build for debugging. Where can I find the source of truth for the debugging build? I don't even know how it finds the wrong paths since I have deleted those from my environment variables and restarted VSCode and my computer, with no changes.

Posted: **Thu Dec 01, 2022 10:56 pm**

To Add more information, I have tried two different debugging launches. One is the play button on the bottom ribbon towards the right, and the other is in the debugging menu in the top left. However, once the button in the top left has been used, a new button in the bottom ribbon shows up (closer to the right). That button seems to use the launch.json file, but the right button in the ribbon is mysterious as far as its source of truth.

With the left buttons I get and error message with these errors:

Code: Select all

1: (208) EXCEPTION: System.ArgumentNullException
1: (208) EXCEPTION:    at MICore.LaunchCommand..ctor(String commandText, String description, Boolean ignoreFailures, Action`1 failureHandler, Func`2 successHandler, Func`2 successResultsHandler)
1: (208) EXCEPTION:    at MICore.LaunchCommand.<>c.<CreateCollection>b__17_0(SetupCommand x)
1: (208) EXCEPTION:    at System.Linq.Enumerable.SelectListIterator`2.ToList()
1: (208) EXCEPTION:    at System.Linq.Enumerable.ToList[TSource](IEnumerable`1 source)
1: (208) EXCEPTION:    at MICore.LaunchCommand.CreateCollection(List`1 source)
1: (208) EXCEPTION:    at MICore.LaunchOptions.InitializeCommonOptions(BaseOptions options)
1: (208) EXCEPTION:    at MICore.LocalLaunchOptions.CreateFromJson(JObject parsedOptions)
1: (209) EXCEPTION:    at MICore.LaunchOptions.GetInstance(HostConfigurationStore configStore, String exePath, String args, String dir, String options, Boolean noDebug, IDeviceAppLauncherEventCallback eventCallback, TargetEngine targetEngine, Logger logger)
1: (209) EXCEPTION:    at Microsoft.MIDebugEngine.AD7Engine.Microsoft.VisualStudio.Debugger.Interop.IDebugEngineLaunch2.LaunchSuspended(String pszServer, IDebugPort2 port, String exe, String args, String dir, String env, String options, enum_LAUNCH_FLAGS launchFlags, UInt32 hStdInput, UInt32 hStdOutput, UInt32 hStdError, IDebugEventCallback2 ad7Callback, IDebugProcess2& process)
1: (218) Send Event AD7MessageEvent

The only information that I have found so far on it is that something in the back end is probably getting a NULL argument passed into the MIdebugger causing it to fail on startup. I can't find what mechanism does that.

I also tried a new computer with a fresh install of VSCode and ESP-IDF, and found the same result.

Posted: **Thu Jan 19, 2023 9:31 pm**

I found some of my dumb mistakes, but I'm not quite there yet.

In several places instead of typing "text" I typed "test". Somehow that leads to a NULL argument exception. It makes more sense now, but if anyone runs into a "EXCEPTION: System.ArgumentNullException" it may be a misspelled keyword like I had.

Now the it looks like GDB is looking for port 3333 on localhost and is unable to open it. That looks like OpenOCD is not running, but I have a "prerun" functions that should start that. I'm going to have a closer look into that and see if it is not starting of setting up ports correctly.

Posted: **Thu Jan 19, 2023 11:41 pm**

With more testing, I realized that my preRun task has some bad syntax and was silently not starting OpenOCD. I manually started it with "openocd -f board/esp32c3-builtin.cfg" in a terminal. That would start debugging, but not a the terminal logging. I started that and then I could not start debugging again for a while. Can terminal logging and GDB debugging not be run concurrently?

ESP32 Forum

ESP32C3 with OpenOCD

ESP32C3 with OpenOCD

Re: ESP32C3 with OpenOCD

Re: ESP32C3 with OpenOCD

Re: ESP32C3 with OpenOCD

Re: ESP32C3 with OpenOCD

Re: ESP32C3 with OpenOCD

Re: ESP32C3 with OpenOCD

Re: ESP32C3 with OpenOCD