We hope we’re not insulting you by suggesting this, but it’s possible that even the best among us may be faced with bugs in our embedded code from time to time. And while we’re great fans of
printf debugging over the serial port, and its high-speed equivalent — flipping a GPIO pin — there’s a time when your bug is so deep that having a real debugger is the best way to dig it out.
[slaff] has been doing some great work documenting C/C++ programming on the ESP-8266, mostly using Eclipse and some of the Arduino libraries. In the fourth part of his series of posts, he walks through using a couple debugger options for the ESP. What makes this all work is the ESP-gdbstub code from Espressif themselves. gdbstub looks great — it works both with the standard SDK as well as with FreeRTOS, so you can debug your ESP-8266 code whether it’s in an OS or on the bare metal. And all this just using the standard serial connection that’s used for programming.
Now, this still may not help with timing-related bugs. ESP-gdbstub uses the serial port, after all. But having the ability to set breakpoints and interactively inspect what’s going on in the chip’s memory is priceless, and doing so with no extra hardware connections is brilliant.
When the shat hits the fin, and you really need to JTAG up on your ESP, there’s also been a bunch of work recently on OpenOCD for the ESP-8266 target. In particular, this fork on GitHub has full support for breakpoints, interrupts, watchdog handling, and continuation. But for day-to-day debugging, it’s hard to beat the simplicity of gdbstub.
And if you just want to see what all this debugging hubbub is about, check out our own [Mike Szczys]’s great video demo of using OCD to fix a problem in his snake code.