@@ -9,8 +9,8 @@ My ESP crashes running some code. How to troubleshoot it?
9
9
- `What is the Cause of Restart? <#what-is-the-cause-of-restart >`__
10
10
- `Exception <#exception >`__
11
11
- `Watchdog <#watchdog >`__
12
- - `Check Where the Code Crashes < #check-where-the-code-crashes >`__
13
- - `Other Causes for Crashes <#other-causes-for-crashes >`__
12
+ - `Exception Decoder < #exception-decoder >`__
13
+ - `Other Common Causes for Crashes <#other-causes-for-crashes >`__
14
14
- `If at the Wall, Enter an Issue
15
15
Report <#if-at-the-wall-enter-an-issue-report> `__
16
16
- `Conclusion <#conclusion >`__
@@ -161,8 +161,8 @@ out before restart, you should be able to narrow down part of code
161
161
firing the h/w wdt reset. If diagnosed application or library has debug
162
162
option then switch it on to aid this troubleshooting.
163
163
164
- Check Where the Code Crashes
165
- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
164
+ Exception Decoder
165
+ ~~~~~~~~~~~~~~~~~
166
166
167
167
Decoding of ESP stack trace is now easy and available to everybody
168
168
thanks to great `Arduino ESP8266/ESP32 Exception Stack Trace
@@ -183,21 +183,25 @@ If you don't have any code for troubleshooting, use the example below:
183
183
Serial.println();
184
184
Serial.println("Let's provoke the s/w wdt firing...");
185
185
//
186
- // wait for s/w wdt in infinite loop below
186
+ // provoke an OOM, will be recorded as the last occured one
187
+ char* out_of_memory_failure = (char*)malloc(1000000);
187
188
//
189
+ // wait for s/w wdt in infinite loop below
188
190
while(true);
189
191
//
190
192
Serial.println("This line will not ever print out");
191
193
}
192
194
193
195
void loop(){}
194
196
195
- Upload this code to your ESP (Ctrl+U) and start Serial Monitor
196
- (Ctrl+Shift+M). You should shortly see ESP restarting every couple of
197
- seconds and ``Soft WDT reset `` message together with stack trace showing
198
- up on each restart. Click the Autoscroll check-box on Serial Monitor to
199
- stop the messages scrolling up. Select and copy the stack trace, go to
200
- the *Tools * and open the *ESP Exception Decoder *.
197
+ Enable the Out-Of-Memory (*OOM *) debug option (in the *Tools > Debug Level *
198
+ menu), compile/flash/upload this code to your ESP (Ctrl+U) and start Serial
199
+ Monitor (Ctrl+Shift+M). You should shortly see ESP restarting every couple
200
+ of seconds and ``Soft WDT reset `` message together with stack trace showing
201
+ up on each restart. Click the Autoscroll check-box on Serial Monitor to
202
+ stop the messages scrolling up. Select and copy the stack trace, including
203
+ the ``last failed alloc call: ... `` line, go to the *Tools * and open the
204
+ *ESP Exception Decoder *.
201
205
202
206
.. figure :: pictures/a02-decode-stack-tace-1-2.png
203
207
:alt: Decode the stack trace, steps 1 and 2
@@ -263,7 +267,7 @@ Asynchronous Callbacks
263
267
can happen.
264
268
265
269
Memory, memory, memory
266
- Running out of heap is the most common cause for crashes. Because the build process for
270
+ Running out of heap is the ** most common cause for crashes ** . Because the build process for
267
271
the ESP leaves out exceptions (they use memory), memory allocations that fail will do
268
272
so silently. A typical example is when setting or concatenating a large String. If
269
273
allocation has failed internally, then the internal string copy can corrupt data, and
@@ -287,6 +291,11 @@ Memory, memory, memory
287
291
rely on exceptions for error handling, which is not available for the ESP, and in any
288
292
case there is no access to the underlying code.
289
293
294
+ Instrumenting the code with the OOM debug option and calls to ``ESP.getFreeHeap() `` will
295
+ help the process of finding leaks. Now is time to re-read about the
296
+ `exception decoder <#exception-decoder >`__.
297
+
298
+
290
299
*Some techniques for reducing memory usage *
291
300
292
301
* Don't use const char * with literals. Instead, use const char[] PROGMEM. This is particularly true if you intend to, e.g.: embed html strings.
0 commit comments