VisualGDB noob having no success with any debugging method on ESP8266

[nathanwiebe]

I believe there is massive potential in the VisualGDB tools.  I am very open to replacing our current dev tools for both ARM and ESP8266 across our organization, but I am having a bit of a bumpy start.  I am brand new to the VisualGDB platform, and to tools like OpenOCD and GDB in general.  I have a few projects under my belt on the ESP8266 – I have worked with a number of different boards, using NodeMCU and Arduino platforms.  Using VisualGDB, I have not been successful at getting any method of in-circuit debugging going on the ESP, and I would love to know if there is something obvious I am doing wrong.

My platform is Windows 10 Pro, Visual Studio 2015, and I am using the latest version of VisualGDB downloaded this weekend.  I am using an ESP-12E module on a NodeMCU v2 board, with FLASH size and configuration known to work with the VisualGDB defaults for my particular ESP module variant (40MHz/QIO/4M – matching the Arduino settings I use).

Here is what I’ve tried:

1. I followed the UART GDB Stub tutorial verbatim.  The device programs (LED blinking normally during programming), but all GDB commands afterwards seem to time out (e.g. “target remote \\.\COM3”, “-exec-continue”, etc).  I will attach the GDB log in a comment below for inspection.  The log seems to suggest the GDB quit unexpectedly, so I really don’t know where to start in troubleshooting that one.
2. I followed the “Debugging ESP8266 code with OpenOCD and Visual Studio” tutorial verbatim.  I tried 2 different working J-Links, with the same result.
   1. Initially, I got a “Error: libusb_open() failed with LIBUSB_ERROR_NOT_SUPPORTED” error.  Based on some googling, it seemed that I should use the libusb driver.
   2. So… I grabbed the VisualGDB USB Driver Tool, and tried to switch the J-Link driver to “Libusb – WinUSB” and get the following error: “Cannot install the selected driver: Unknown error (0xe0000203)”.
   3. Using the “WinUSB” option (instead of “Libusb – WinUSB”), the driver swap works.  It actually does go through the programming sequence as I would expect, but as soon as it finishes I get a “Received a SIGTRAP: Trace/breakpoint trap” error from Visual Studio.  The error is repeatedly thrown if I hit continue at that point.  Hitting break leaves me in a “Source Not Available” error, and disassembly shows my PC to be at 0x4000dc4b, in an area full of “ill” instructions.
   4. In all scenarios the “Detect” button on the “VisualGDB Project Properties -> Debug settings -> Programming interface” dialog detects the J-Link successfully.  (As an aside, here is a form bug report: When OpenOCD is selected, changing the Programming interface does mark the configuration as dirty/changed – i.e. the Apply button at the bottom stays disabled, and the configuration change is not saved if you change the interface and click OK.  You have to change something else to get the Apply button enabled.  But I digress…)
   5. Obviously based on the above, I do not have sufficient evidence to confirm one way or another that my JTAG pin connections are correct, but the J-Link is blinking and doing something for about 10 seconds while the programming progress bar goes from 0% to 100% for the programming operation, for what it’s worth.
   6. I have tried connecting the ESP’s reset pin to JTAG20 pin 3, JTAG20 pin 15, and JTAG20 pin 3 and 15 all with the same results (Note that there seems to be a possible disagreement between the red text regarding the reset pins on the two tutorials (http://visualgdb.com/tutorials/esp8266/) and (http://visualgdb.com/tutorials/esp8266/openocd/), so I tried both ways.  (The wording on the first tutorial is unclear as to whether JTAG20-pin15 should be disconnected, or whether all 3 should be connected.  A new schematic dedicated to the OpenOCD connections would be worth 1000 words).

Any help would be massively appreciated.  Please let me know if there is any relevant information I have left out.

[nathanwiebe]

As promised, here is the GDB log from the UART GDB Stub attempts:

Your VisualGDB trial expires in 30 days!
C:\SysGCC\esp8266\bin\xtensa-lx106-elf-gdb.exe –interpreter mi C:\Projects\ESP_UARTGDBStub\ESP_UARTGDBStub/Debug/ESP_UARTGDBStub.elf
-gdb-version
=thread-group-added,id=”i1″
GNU gdb (GDB) 7.11
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html&gt;
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type “show copying”
and “show warranty” for details.
This GDB was configured as “–host=i686-pc-mingw32 –target=xtensa-lx106-elf”.
Type “show configuration” for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/&gt;.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/&gt;.
For help, type “help”.
Type “apropos word” to search for commands related to “word”…
Reading symbols from C:\Projects\ESP_UARTGDBStub\ESP_UARTGDBStub/Debug/ESP_UARTGDBStub.elf…
done.
GNU gdb (GDB) 7.11
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html&gt;
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type “show copying”
and “show warranty” for details.
This GDB was configured as “–host=i686-pc-mingw32 –target=xtensa-lx106-elf”.
Type “show configuration” for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/&gt;.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/&gt;.
For help, type “help”.
Type “apropos word” to search for commands related to “word”.
OK
-list-features
^done,features=[“frozen-varobjs”,”pending-breakpoints”,”thread-info”,”data-read-memory-bytes”,”breakpoint-notifications”,”ada-task-info”,”language-option”,”info-gdb-mi-command”,”undefined-command-error-code”,”exec-run-start-option”]
-gdb-set stop-on-solib-events 1
OK
-gdb-set disassembly-flavor intel
No symbol “disassembly” in current context.
-gdb-set print demangle off
OK
-break-insert -f main
&”Function \”main\” not defined.\n”
^done,bkpt={number=”1″,type=”breakpoint”,disp=”keep”,enabled=”y”,addr=”<PENDING>”,pending=”main”,times=”0″,original-location=”main”}
Warning: could not set a breakpoint on main. ‘Step into new instance’ will not work.
-break-delete 1
OK
set serial baud 74800
&”set serial baud 74800\n”
=cmd-param-changed,param=”serial baud”,value=”74800″
OK
target remote \\.\COM3
&”target remote \\\\.\\COM3\n”
Remote debugging using \\.\COM3
Loaded image in 10649 ms
&”Quit (expect signal SIGINT when the program is resumed)\n”
Quit (expect signal SIGINT when the program is resumed)
System.Exception: GDB has exited prematurely

at VisualGDB.GDBDebugEngine.a(adv A_0)

[support]

Hi,

OK, this looks like a wiring problem. Regarding UART, please try opening the port in SmarTTY (using 74880 baud rate) and resetting the board. Do you see any output? If not, please try experimenting with the baud rate, perhaps the device is not detecting the crystal frequency properly.

Regarding JTAG, the ESP8266 chip is very unstable and sensitive to things like timings, so the easiest way to see if anything is working at all is to create a project based on the NOFLASH device and see if it can work. If not, please share your OpenOCD log so that we could check it for common errors. If the NOFLASH example works, but the regular one does not, please try experimenting with the “Device reset mode” in the debug settings. If this does not help, please share the GDB and OpenOCD log of the unsuccessful JTAG session so that we could give further advice.

[nathanwiebe]

Ok, I believe I have figured out what is up with the UART GDB stub.  The NodeMCU v2 board controls the RESET and GPIO0/BOOT pins using the USB-UART chip’s flow control outputs (DTR and RTS) – this is the behavior of many many Arduino- and NodeMCU-compatible ESP8266 boards out there, and there is a de facto standard for the pin assignment used by Arduino Studio, VisualMicro, etc.  VisualGDB seems to set the flow control pins in a state that results in GPIO0 being held low, so the micro never boots into run mode after programming.  I do wish VisualGDB could be modified to either support the controlling of these pins via the standard pinout (i.e. have an option to automatically control reset and boot via these pins without having to prompt the user to enter boot mode), or leave them in a state that is compatible with BOOT floating high (so the RTS pin doesn’t override the button on the BOOT pin.)

For now, I am using another dev board I have that doesn’t use the USB-UART flow control pins for controlling RESET and BOOT.

Now…. on to troubleshooting why my JTAG connection isn’t working… (btw I did try the NOFLASH option during my original testing with identical results to the other options.  Thanks for the suggestion though… I will stick to that option until I get up and running on JTAG)

[support]

Hi,

VisualGDB uses the default reset sequence from the Espressif’s esptool.py, but you can override this in the Debug Settings. Simply change the default bootloader sequence (!DTR;RTS;SLEEP;DTR;!RTS;SLEEP;!DTR;SLEEP) to the one that will work with your wiring.

If you cannot get JTAG to work reliably, we recommend using the ESP8266-EVB board from Olimex. It appears to be generally more reliable than the original ESP-xx modules.

 

[Author]

Posts