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.
too funny just on http://www.esp8266.com/viewtopic.php?t=1960 and reading about this…. lots of info on there also with people using it, going to give it a try
Heads up! http://www.esp8266.com/viewtopic.php?t=1871 this also show you the pinouts for the JTAG connections
The hardware debug from OpenOCD is good news. It uses up a lot of I/O, but it is the last resort when the software approach won’t help you. Good to have both alternatives.
This part is looking better and better for the open source community.
I’d be happy if my ESP-12 would reliably start up every time I gave it power… Must’ve gotten a dud or something because this thing is touchy as hell.
Is the power supply clean enough and without spikes? Switches produce spikes and multiple bounces too.
I think so. Haven’t actually scoped it but it’s a simple 1117 based breadboard supply with plenty of caps, should be fine (tried two of them).
make sure you have:
RST -> VCC
GPIO0 -> VCC
GPIO2 -> VCC
CH_PD -> VCC
Switch GPIO0 -> GND when loading code.
don’t forget pin 15 to ground when using an esp-12
Thanks for the tip. I had missed the RST (though I figured it’d be internally pulled up). Still though, no joy. I get it to boot up properly maybe one out of ten times I disconnect and re-connect power. I think my module is simply bugged out.
do you have a cap between RST and ground? that made hell of a difference for me
I have a NodeMCU board. Using their stock NTP demo code, and the NeoPixelsBus library, the damn thing faults and resets all the time.
The ESP8266 should not be used as a whole-system micro. It should only run the network stack, and nothing more.
Same here, bought a few ESP01 from AliExpress, and leave them on. After a few hours or days, the module state looks like it was a reset in the meantime. No firmware upgrade or power supply could fix the random reset. All the ESP modules have the same issue.
Can anybody please report if an ESP8266 can work reliably for a whole week or so? I start to doubt this is possible at all.
:o(
I use them in a lot of my newer clock projects, and I leave them on for weeks at a time without any glitches. Try copying a known good design like adafruit’s huzzah (https://learn.adafruit.com/adafruit-huzzah-esp8266-breakout/downloads), I prototype with those boards all the time and stability is usually a matter of something in the code rather than the board :)
I’ve quite a few of these running for months without a glitch. The key is to provide sufficient power, lets say 300mA at least. I’m placing ~470uF caps for peace of mind too. Next is to ensure your software id free of memory leaks