Debugging ESP8266 with OpenOCD and J-Link

[gigamegawatts]

I’ve recently begun a project using an ESP8266 board, a Segger J-Link and Sysprog’s OpenOCD implementation. I’m using VisualGDB 5.2 and Visual Studio 2015. The board is a NodeMCU clone.

My configuration doesn’t work reliably. Breakpoints are sometimes hit, sometimes not. I can sometimes break into the code while it’s running, but usually I get a GDB timeout if I try. Single-stepping with F10 sometimes works as expected, but sometimes it “steps into” instead of “steps over”.

I’m not sure that I’m using the software properly. I’ve noticed some things in older tutorials — for the Xtensa OCD software, and for using OpenOCD with other processors — and I’m not sure if they also apply to Sysprog’s OpenOCD software for the ESP8266.

So, 3 questions:

1. The “Configuring OpenOCD for JTAG debugging” tutorial (http://visualgdb.com/tutorials/arm/openocd/) says “OpenOCD typically need one of the following drivers: FTDI FT2232 drivers, Libusb drivers.” Does this apply to the ESP8266 OpenOCD, or is Segger’s J-Link driver good enough?

2. The “Developing projects for the ESP8266 WiFi chip with Visual Studio” tutorial (http://visualgdb.com/tutorials/esp8266/), which is for the older Xtensa OCD, says that “As the ESP8266 chip has only one hardware breakpoint, you will only be able to set one breakpoint in a function placed directly to SPI FLASH. Furthermore, while this breakpoint is active, stepping won’t work as it relies on the same hardware breakpoint.” I understand the Sysprog’s OpenOCD implementation fully supports software breakpoints, so this doesn’t apply. Is there any restriction on breakpoints when using Sysprog’s OpenOCD implementation?

3. The “Debugging ESP8266 code with OpenOCD and Visual Studio” tutorial (http://visualgdb.com/tutorials/esp8266/openocd/) says “If you are using OpenOCD, it will automatically feed the ESP8266 watchdog preventing it from restarting your system.” I think this applies to the software watchdog, but does it also apply to the ESP8266’s hardware watchdog? That is, can I assume that watchdogs aren’t causing problems as long as I have that “Feed ESP8266 watchdog” checkbox turned on?

Thanks,

Dan.

[support]

Hi,

Sorry, ESP8266 devices are simply not reliable and highly undocumented and often stop working sporadically. If reliability is a priority, we recommend trying the CC3200 chip from TI. It’s more expensive, but is much more reliable.

Regarding the questions below:

1. OpenOCD does require the libusb driver for Segger J-Link and will not work with the default Segger driver.
2. Our OpenOCD implementation only supports software breakpoints for functions in RAM. We recommend moving the actively debugged functions to RAM for the duration of debugging.
3. Unfortunately there is no official documentation on ESP8266 watchdogs. Our OpenOCD implementation uses the watchdog feeding mechanism used by the Espressif GDB stub. It is sufficient to step through examples like HTTP server, but it could be that some code in the internal ESP8266 libraries activates some mode that conflicts with this mechanism.

Sorry, as mentioned before, the lack of official documentation and general low reliability makes ESP8266 debugging not as smooth as for ARM devices. We try to provide workarounds for most known problems, but in many cases things don’t work as expected.

[freeck]

Hi there,

I had the same experiences as you. I switched to the serial gdbstub-version which is well documented on this site. Its more stable, not perfect, but great to work with. Learn to live with the limitations…..
Advantage of using the serial port is that the jtag IO pins are free for your own application, although the panalty is that the serial port is occupied by the debugger.

Fred

[gigamegawatts]

Hi,

Thanks to you both for the information.

I’ll try updating the J-Link driver and moving more of my code to RAM to see if that improves things.  If not, it’s good to know that it’s not just something wrong with my setup.

Fred, I was originally using the GDB Stub and ran into problems there with breakpoints and single-stepping.  I thought that might be caused by me having moved all of my code into Flash, so I switched to OpenOCD to free up more RAM.  It’s good to know that  GDB Stub isn’t 100% reliable either.  As you say, I can live with the limitations now that I know they exist.

Thanks,

Dan

[freeck]

Hi Dan,

As suggested in one of the tutorials: put the be tested code in IRAM, then it works fine. Most of the hang-ups I experienced had to do with stepping out of your functions and entering systemfunctions. I delt with that by using the run-to-line debug command Or run to a next breakpoint.

[jhinkle]

Dan:

Did you get j-link to work?

I tried it 9 months ago (it was a new feature back the) and ended up using serial.

I’m starting a new project and need the uart to talk to another CPU — so I can’t use serial debug.

Any insight as to getting j-link up and running would be helpful.

Thanks.

Joe

 

 

[Author]

Posts