# ESP8266 “Soft WDT reset” crash: causes and fixes

> Fix the ESP8266 NodeMCU Soft WDT reset: loops that never yield, long delays, and how to read the exception decoder trace.

Canonical: https://roboticsengineering.in/fix/esp8266-soft-wdt-reset/ | Published: 2026-11-03 | Updated: 2026-11-04

**The ESP8266 resets when your code keeps the processor busy so long that its background Wi-Fi tasks cannot run.** Give the system time with short loops and yield().

## What the message means

The ESP8266 runs your sketch and the Wi-Fi stack on one core. A software watchdog resets the chip if your code does not return control within a short time. The serial log shows “Soft WDT reset” and a stack trace.

## Fix it in this order

1. Find loops that wait for something with no exit, such as while (digitalRead(pin) == LOW) with nothing inside.
2. Add delay(1) or yield() inside long loops so the Wi-Fi tasks can run.
3. Replace long delay() calls with millis() based timing.
4. Break big calculations into smaller pieces done across several loop() passes.
5. Use the ESP exception decoder with the stack trace to find the line that caused it.
6. Check for a null pointer or a bad array index. These also crash with a similar trace.

## Why it happens

The ESP8266 runs your sketch and its Wi-Fi stack on a single core. The software watchdog monitors that work, and if the code does not return control to the system within a set period, it resets the chip. A long delay(), a tight while loop waiting on a flag that never changes, or a heavy calculation can each starve the background tasks. The serial output reports the reset, and the stack trace points toward the code that held the processor.

The fix is to let the system run. Replace blocking waits with millis()-based timing so loop() returns quickly. Insert yield() or delay(0) inside long loops so the Wi-Fi stack can be serviced. Large calculations can be split across several passes. Decoding the stack trace with the ESP exception decoder locates the faulty line, which is more reliable than guessing from the symptom.

## If you see this, do this

| You see | Do this |
| --- | --- |
| Resets after a long delay() | Use millis() timing. |
| Resets at one point in code | A loop or call there never returns quickly. |
| The trace mentions an exception number | Decode the trace to find the faulty line. |

## Confirm the fix

1. Print millis() at the top and bottom of the suspect loop, and check that the gap between them stays small on every pass.
2. Insert yield() in the loop you suspect, upload, and confirm the reset stops or moves to a different point in the code.
3. Paste the stack trace from the serial monitor into the ESP exception decoder and note the line it reports in your sketch.

**Common mistake:** Readers assume a soft watchdog reset means the hardware is faulty, when it usually means one piece of code has kept the processor busy too long.

## Related

[ESP32 task watchdog](https://roboticsengineering.in/fix/esp32-task-watchdog-got-triggered/), [low memory](https://roboticsengineering.in/fix/arduino-low-memory-available-stability-problems-f-macro/).

Last reviewed: November 2026. These are the usual causes and the order that finds them fastest. Test on your own board; clones and cables differ.