-
Notifications
You must be signed in to change notification settings - Fork 0
Home
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.
- 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 withgdb
and some failures are so infrequent thatgdb
is just not a viable monitoring tool for the crash. - 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 toloop: 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 byets_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 ...