WiFi becomes unreachable / device reboots after "Cancelling WiFi STA Scan..." loops indefinitely

[Grand-Ralph]

Hardware

ESP32

Firmware version

Reproduced on both v2.4.6 and v2.4.7

Application version

v2.4.6/v2.4.7

What happened? What did you expect to happen?

Hardware:

• ESP32 (WROOM-32), diymore ESP32 NodeMCU dev board, CH340, USB-C,
• CC1101 433MHz transceiver (SPI)

What happened?

• The device only connects to WiFi sporadically, and once connected, loses the connection again at irregular intervals. Even when a connection is established, it is often unresponsive (web UI, socket, ping all fail).
• However, when logging the communication over the serial interface (115200 baud, e.g. python -m serial.tools.miniterm COM4 115200 or any terminal program reading the port), the connection remains stable and responsive for hours.

While investigating why serial logging would have any effect on WiFi stability at all, I found that the serial log shows a "Cancelling WiFi STA Scan..." message being printed in an extremely tight loop (multiple times per millisecond).

The loop first appeared during initial device setup, in the following sequence:

1. Flashed the firmware, started a serial monitor (115200 baud), then powered on the device
2. Connected to the device's AP (192.168.4.1) via a mobile phone
3. Under System > Options: set hostname and timezone, disabled "Broadcast UPnP over SSDP" and "Auto Check for Updates", pressed SAVE
4. Under Radio: set RX to GPIO 14, checked "Enable Radio", pressed SAVE RADIO
5. Under Network > Adapter: disabled "Enable Roaming", pressed SCAN, selected my WiFi network, entered the passphrase, pressed SAVE ADAPTER
6. At this point Cancelling WiFi STA Scan... started appearing in the log
7. Switched to System > Options and pressed REBOOT

From that point on, the device would no longer connect reliably, and the log showed the pattern described below.

How to reproduce it (step by step)

1. Flash v2.4.6 or v2.4.7 to an ESP32 WROOM-32 board with a CC1101 radio attached (RX:14, TX:13, SCK:18, MISO:19, MOSI:23, CSN:5)
2. Start a serial monitor (115200 baud), then power on the device
3. Connect to the device's AP (`192.168.4.1`), go through initial setup (hostname, timezone, disable SSDP broadcast and auto-update-check, configure and enable the radio)
4. Under **Network > Adapter**, press **SCAN**, select your WiFi network, enter the passphrase, and press **SAVE ADAPTER**
5. Observe the serial log: shortly after `(evt) Completed scan for access points (N)`, the device starts spamming `Cancelling WiFi STA Scan...`
6. After anywhere from a few seconds to ~80 seconds of this loop, the WiFi becomes unresponsible/unreachable.

Logs

# Log excerpt (v2.4.7, fresh/unconfigured board, ~78 seconds of spam, thousands of lines omitted)


[16:00:50.075] (evt) Completed scan for access points (5)
[16:00:50.076] Scanned 5 networks
[16:00:50.092] Timing WebServer: 4718ms
[16:01:09.067] Cancelling WiFi STA Scan...
[16:01:09.071] Cancelling WiFi STA Scan...
[16:01:09.075] Cancelling WiFi STA Scan...
... (repeats every ~4ms, thousands of times) ...
[16:02:08.011] Cancelling WiFi STA Scan...
[16:02:08.015] Cancelling WiFi STA Scan...
[16:02:08.122] (evt) Completed scan for access points (0)
[16:02:08.125] (evt) WiFi clients stopped
[16:02:08.126] (evt) WiFi SoftAP Stopped
[16:02:08.160] ets Jul 29 2019 12:21:46

rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
...


## Log excerpt (v2.4.6, same board, ~17 seconds of spam)


[16:44:09.244] (evt) Completed scan for access points (6)
[16:44:09.245] Scanned 6 networks
[16:44:09.259] Timing WebServer: 3035ms
[16:44:24.034] Cancelling WiFi STA Scan...
[16:44:24.037] Cancelling WiFi STA Scan...
... (repeats every ~4ms, ~3500 times) ...
[16:44:41.457] Cancelling WiFi STA Scan...
[16:44:41.564] (evt) Completed scan for access points (0)
[16:44:41.567] (evt) WiFi clients stopped
[16:44:41.568] (evt) WiFi SoftAP Stopped
[16:44:41.612] ets Jul 29 2019 12:21:46

rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
...


## Testing matrix (to rule out hardware/config causes)

I spent considerable time isolating this, since at first it looked like a power-supply/hardware issue (the connection was stable for hours whenever a serial monitor was actively reading the debug output, and became unstable within minutes whenever nothing was reading the serial port — even when powered from a good quality 3A supply with no PC attached at all). The following were all ruled out as the cause:

| Variable tested | Result |
|---|---|
| Board 1 (diymore ESP32, with added 470µF decoupling cap on 3.3V/GND) | Problem occurs |
| Board 2 (second, unmodified diymore ESP32 from the same batch) | Problem occurs |
| Firmware v2.4.7 | Problem occurs |
| Firmware v2.4.6 | Problem occurs |
| `ssdpBroadcast: false` | No change |
| `checkForUpdate: false` | No change |
| WiFi roaming disabled | No change |
| MQTT disabled | No change (was already off) |
| Serial monitor actively reading debug output | Connection stable for hours |
| Serial port open but not read (idle DTR/RTS) | Connection unstable, same as no serial at all |
| No serial connection, powered from wall adapter only | Connection unstable |
| Full power-cycle after a failed connection | Does not reliably restore connectivity |

The correlation with "serial monitor actively reading" appears to be a red herring / side-effect: I believe actively draining the serial output happens to slow down or interrupt the tight scan-cancel loop just enough to let the WiFi/network stack get some CPU time, which is why it looked at first like a power or hardware issue.

## Suspected root cause

Something in the WiFi scan / reconnect logic triggers `WiFi.scanNetworks()` (or similar) periodically, and the corresponding cancel/cleanup path appears to spin in a tight loop under some condition instead of completing, starving the WiFi and web server tasks of CPU time until the watchdog (added per the v2.x changelog: "Added 7 second watchdog timer. If any process halts for more than 7 seconds the ESP32 will reboot") eventually reboots the device — but not always before the network stack has already effectively died.