WiFi Corruption on Field-Deployed ESP32 ICS Devices – Unresponsive WiFi Layer Requires Router Restart (IDFGH-14703)

[filzek]

Answers checklist.

• I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report

ESP-IDF 5.4 updated to the latest commit bcb3c32 (HEAD -> release/v5.4, origin/release/v5.4)
Merge: c93d7d0 8ad144a
Author: morris [email protected]
Date: Tue Feb 18 22:53:26 2025 +0800
Merge branch 'bugfix/sdmmc_reset_pins_slot_width_v5.4' into 'release/v5.4'
fix(sdmmc): fix reset of pins above slot width (v5.4)
See merge request espressif/esp-idf!36874

We have observed a WiFi corruption issue on our field-deployed devices using ESP32 ICS. In our development/debug builds, the problem does not occur; however, in production firmware the WiFi layer eventually becomes unresponsive. Restarting the router temporarily restores connectivity, but this is not a viable solution for customers in the field.

Issue Details
Symptoms:

• The device’s WiFi becomes extremely unresponsive.
• Only a router restart (tested on a DECO M5 using the 2.4GHz network in BGN mode) temporarily resolves the issue.
• Other devices on the same network maintain normal speeds and packet transmission, indicating the problem is isolated to the ESP32 WiFi layer.
• Observations:
• We are collecting WiFi metrics using esp-insights. One of the affected devices shows healthy heap status with plenty of free memory and no fragmentation issues:

[1740147730] - esp_diag_heap_metri
cs_dump & esp_diag_wifi_metrics_dump ran!
[1740147742] - Heap Info:
[1740147742] - Free bytes: 26787
[1740147742] - Allocated bytes: 262356
[1740147742] - Largest free block: 19456
[1740147742] - Min free ever: 19963
[1740147742] - Free blocks: 11
[1740147742] - Allocated blocks: 473

• The metrics suggest that the issue is not due to memory exhaustion or fragmentation.
• Environment:
• Devices: ESP32 Wrover IE 16mb 16mb
• Router: DECO M5 (2.4GHz in BGN mode).

NOTICE: Processing 16 dependencies:
NOTICE: [1/16] espressif/button (4.0.0)
NOTICE: [2/16] espressif/cbor (0.6.0~1)
NOTICE: [3/16] espressif/cmake_utilities (0.5.3)
NOTICE: [4/16] espressif/esp-radar (0.2.0)
NOTICE: [5/16] espressif/esp_audio_codec (2.2.0)
NOTICE: [6/16] espressif/esp_diag_data_store (1.0.2)
NOTICE: [7/16] espressif/esp_diagnostics (1.2.1)
NOTICE: [8/16] espressif/esp_insights (1.2.3)
NOTICE: [9/16] espressif/esp_websocket_client (1.4.0)
NOTICE: [10/16] espressif/mdns (1.7.0)
NOTICE: [11/16] espressif/rmaker_common (1.4.6)
NOTICE: [12/16] joltwallet/littlefs (1.16.4)
NOTICE: [13/16] jschwefel/esp-idf-ds3231 (1.0.3)
NOTICE: [14/16] nimble_peripheral_utils () (C:\Espressif\frameworks\esp-idf-v5.4\examples\bluetooth\nimble\common\nimble_peripheral_utils)
NOTICE: [15/16] protocol_examples_common () (C:\Espressif\frameworks\esp-idf-v5.4\examples\common_components\protocol_examples_common)
NOTICE: [16/16] idf (5.4.0)

Services Running

• MDNS
• Websocket WS
• Ping to same LWIP IP of the device every minute, with non destructible task,
• Ping server IP minute, with non destructible task,
• Nimble BLE Scan every 3 minutes
• Http local server to show debugs

The board do not crash but the WiFi become irresponsive, BLE still responsive, WiFi become suffering to simple access the http server page.

To solve immediate the problem:
Reboot the WiFi network

So, this seens a problem in the WiFi layer that become corrupt somewhere/somehow.

If need we can add any code refered to send data to the esp-insight as needed

[filzek]

A new information, when the problem happen the DHCP server looses the IP and cant get a new IP. So, even the esp_wifi_connect(); in the event handler being called, it simples quite working.

[filzek]

We got the problem so far, the DHCP layer sometime fail and leave the system without IP.

Also, sometimes the handler of IP will not update if the STOP and START dhcp is done without we cleaning the IP address.

So, maybe an way to solve this is to zeroes the IP once the wifi disconnet.