Skip to content
M Hightower edited this page May 16, 2023 · 9 revisions

Welcome to the AbendInfo Wiki!

Objective/Goal: To get a better understanding of an ESP8266 crash. In particular, the ever frustrating inexplicable Hardware WDT Reset and the Software WDT Reset.

Generally, Hardware WDT Reset and Software WDT Reset crashes are thought to be the result of an Infinite Loop. However, they are not always directly caused by the user's Sketch.

  1. Some are the results of unhandled breakpoints in the SDK or Boot ROM, and others result from unhandled exceptions which fall into the unhandled breakpoint path. These breakpoints can usually be caught with gdb. However, nobody runs their sketch all the time with gdb and some failures are so infrequent that gdb is just not a viable monitoring tool for the crash.
  2. Another group of causes for WDT Reset crashes, are Deliberate Infinite Loops. In "C" code, these are commonly written as while(true){/* empty */}. In asm, this compiles down to loop: j loop. Which has the byte pattern 0x06, 0xff, 0xff. If you search through SDK v3.0.5 you can find about 95 of these. 94 of these Infinite Loops are preseeded by ets_printf which does nothing unless you have a console connected and have debug printting enabled. When you think about it, Deliberate Infinite Loops is not an unreasonable way to handle an unrecoverable event; however, not providing a clue for the WDT reset is intolerable. And, even if we were able the see the "last gasp" error message they are not documented. When interrupts are enabled these Infinite Loops present as Software WDT Resets which can give you some clue of the location of the crash; however, when interrupts are disabled, you get zero details only a Hardware WDT Reset.

The root cause or stimulus for these (IMO) is often low heap space.

To be continued ...

Clone this wiki locally