Critical Regression: Core 0/1 Panic (WDT/Abort) during SD File Serving on ESP32 Dual

[Michael-Wilt]

Hola ESP32 Async, mucho gusto en saludarlos, les escribo para solicitar por favor su ayuda con lo siguiente:

Descripción General:
Desde las actualizaciones de las últimas 2 a 3 semanas, he detectado una inestabilidad crítica al servir archivos estáticos (HTML, CSS, Imágenes) desde una tarjeta SD utilizando un ESP32 con las librerías ESPAsyncWebServer y AsyncTCP.

El problema se manifiesta como un reinicio por panic o abort() en ambos núcleos, incluso cuando los archivos solicitados son extremadamente pequeños (~1KB). Cabe destacar que el código fuente de mi aplicación no ha sufrido cambios desde mediados de enero; sin embargo, tras aceptar las actualizaciones automáticas de las librerías mencionadas en el IDE de Arduino, el sistema se volvió inestable.

Objetivo:
Mi intención no es retroceder de versión, sino encontrar la configuración correcta para el entorno actual. Agradecería sugerencias sobre:

• Ajustes recomendados en los parámetros de AsyncTCP para evitar colisiones de bus.
• Manejo óptimo de archivos pequeños en SD para reducir el estrés en el stack asíncrono.
• Configuración de prioridades de tareas para proteger la ejecución en el Core 0.

Hallazgos Clave sobre la Persistencia (Efecto en Hardware):
He realizado pruebas cruzadas que sugieren una alteración persistente en el entorno de ejecución del chip:

Al descargar el programa actualizado a un ESP32 que funcionaba correctamente con versiones anteriores, este comenzó a reiniciarse de forma inmediata y aleatoria.

Intentar revertir ("downgrade") las librerías a versiones previas no soluciona el problema una vez que el chip ha sido expuesto a la nueva versión, lo que sugiere que la actualización podría estar alterando parámetros de bajo nivel (como la configuración del SDK, el Bootloader, o la gestión de la NVS/Flash) que permanecen en el dispositivo.

Análisis del Panic:

Core 0 Panic: Ocurre un abort() o WDT Timeout aproximadamente 100ms después de que el servidor (en el Core 1) termina de procesar una petición (Processed in XX ms). Esto indica una posible contención del bus SPI/Flash (Bus Contention) que bloquea las tareas de mantenimiento del sistema en el Core 0.

Core 1 Panic: Se observa un abort() durante el parseo de cabeceras HTTP (ej. al leer el User-Agent) en peticiones consecutivas de archivos pequeños (iconos de 1KB), lo que apunta a una corrupción de memoria o un desbordamiento de pila (stack overflow) en el stack TCP asíncrono.

Entorno de Reproducción:

Hardware: ESP32 Dual Core.
Almacenamiento: Tarjeta SD vía bus SPI.
Configuración: Aplicación principal aislada en el Core 0, servidor corriendo en el Core 1.
Síntoma: El sistema falla aleatoriamente tras servir un archivo CSS, javascript o al intentar cargar múltiples imágenes pequeñas de forma simultánea.
Versiones: La versión más actualizada a la fecha 14.02.2026 de Arduino IDE y de las librerías ESPAsyncWebServer y AsyncTCP.

Evidencia de Fallos (Logs de Eventos)
A continuación, presento dos escenarios de error reproducibles que demuestran la inestabilidad tras la actualización:

ESCENARIO 1: Pánico en Core 0 tras servir archivos CSS (Bloqueo de Bus/WDT)
En esta prueba, el servidor entrega con éxito el HTML y el CSS. Sin embargo, exactamente 116ms después de finalizar el procesamiento del CSS (Processed in 67 ms), el Core 0 lanza un abort(). Esto sugiere que la tarea de limpieza del servidor en el Core 1 está colisionando con las tareas de mantenimiento del sistema en el Core 0.

07:45:25.546 -> * Connection from 192.168.1.36:61802
07:45:25.546 -> > GET / HTTP/1.1
07:45:25.546 -> > Host: esp32.local
07:45:25.546 -> > Connection: keep-alive
07:45:25.546 -> > Upgrade-Insecure-Requests: 1
07:45:25.546 -> > User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/145.0.0.0 Safari/537.36
07:45:25.594 -> > Sec-Purpose: prefetch;prerender
07:45:25.594 -> > Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.7
07:45:25.594 -> > Accept-Encoding: gzip, deflate
07:45:25.594 -> > Accept-Language: es-ES,es;q=0.9,en;q=0.8
07:45:25.594 -> >
07:45:25.770 -> * Processed in 203 ms
07:45:25.770 -> < HTTP/1.1 200 OK
07:45:25.812 -> < Content-Disposition: inline
07:45:25.812 -> <
07:45:27.135 -> * Connection from 192.168.1.36:61801
07:45:27.135 -> > GET /css/style_login.css HTTP/1.1
07:45:27.135 -> > Host: esp32.local
07:45:27.135 -> > Connection: keep-alive
07:45:27.135 -> > User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/145.0.0.0 Safari/537.36
07:45:27.135 -> > Sec-Purpose: prefetch;prerender
07:45:27.135 -> > Accept: text/css,/;q=0.1
07:45:27.182 -> > Referer: http://esp32.local/
07:45:27.182 -> > Accept-Encoding: gzip, deflate
07:45:27.182 -> > Accept-Language: es-ES,es;q=0.9,en;q=0.8
07:45:27.182 -> >
07:45:27.269 -> * Processed in 67 ms
07:45:27.269 -> < HTTP/1.1 200 OK
07:45:27.269 -> < Content-Disposition: inline
07:45:27.269 -> < ETag: "69168c42"
07:45:27.269 -> < Cache-Control: no-cache
07:45:27.269 -> <
07:45:27.385 ->
07:45:27.385 -> abort() was called at PC 0x400830f7 on core 0 ... 07:45:27.385 ->
07:45:27.385 ->
07:45:27.385 -> Backtrace: 0x4008d8f0:0x3ffd1ca0 0x4008d8b5:0x3ffd1cc0 0x40093ee1:0x3ffd1ce0 0x400830f7:0x3ffd1d60 0x4008313a:0x3ffd1d80 0x4008329d:0x3ffd1db0 0x40103811:0x3ffd1dd0 0x40108075:0x3ffd1e00 0x4000bd83:0x3ffd1e20 0x4000182a:0x3ffd1e40 0x401076d9:0x3ffd1e60 0x40108075:0x3ffd1e80 0x40089aea:0x3ffd1ea0 0x400884b1:0x3ffd1ec0 0x40088503:0x3ffd1ee0 0x400889bd:0x3ffd1f00 0x40195d7f:0x3ffd1f30 0x40195c76:0x3ffd1f50 0x4018a925:0x3ffd2270 0x40093d19:0x3ffd22a0 0x40141dcd:0x3ffd2300 0x40114c2d:0x3ffd2340 0x40118203:0x3ffd2380 0x4011d30e:0x3ffd23b0 0x4010aa8e:0x3ffd23d0 0x4008e705:0x3ffd2400
07:45:27.418 ->
07:45:27.418 ->
07:45:27.459 ->
07:45:27.459 ->
07:45:27.459 -> ELF file SHA256: c86fd9e17
07:45:27.459 ->
07:45:27.588 -> Rebooting...

ESCENARIO 2: Pánico en Core 1 durante el parseo de Headers (Corrupción de Memoria)
Tras el reinicio anterior, el navegador intenta recuperar los recursos faltantes (imágenes). En este caso, el ESP32 falla inmediatamente al recibir la petición de un icono de solo 1KB. El log se corta abruptamente durante la lectura del User-Agent, y el pánico ocurre esta vez en el Core 1, lo que apunta a un desbordamiento o puntero nulo en el stack asíncrono.

07:57:48.752 -> * Connection from 192.168.1.36:62260
07:57:48.752 -> > GET /img/icon_lock_001.png HTTP/1.1
07:57:48.752 -> > Host: esp32.local
07:57:48.752 -> > Connection: keep-alive
07:57:48.752 -> > User-Agent
07:57:48.752 -> abort() was called at PC 0x40180733 on core 1
07:57:48.752 ->
07:57:48.752 ->
07:57:48.752 -> Backtrace: 0x4008d8f0:0x3fff6b00 0x4008d8b5:0x3fff6b20 0x40093ee1:0x3fff6b40 0x40180733:0x3fff6bc0 0x40180768:0x3fff6be0 0x40181035:0x3fff6c00 0x401808c5:0x3fff6c20 0x400eea09:0x3fff6c40 0x400eeb6f:0x3fff6c80 0x400ee1dd:0x3fff6cc0 0x400d7c9f:0x3fff6cf0 0x400d7d7e:0x3fff6d40 0x4008e705:0x3fff6d60
07:57:48.787 ->
07:57:48.787 ->
07:57:48.787 ->
07:57:48.787 ->
07:57:48.787 -> ELF file SHA256: c86fd9e17
07:57:48.787 ->
07:57:48.909 -> Rebooting

[mathieucarbou]

Hi @Michael-Wilt,
Please write in english.
Even if I could nearly understand, pretty much all the people are english speakers so you need also to write in english if your goal is to seek help and expect people to read you.
Thank you!

[mathieucarbou]

Also:

• For the Backtrace: please translate them with https://esphome.github.io/esp-stacktrace-decoder/

• Specify which version of the libs you are using and make sure these are the latest versions are that they come from our organization. Many people have forked them in the past and deployed them in arduino lib registry which is a mess

• Have a look at the examples in the project to see if you are doing something wrong

• Share your code: nobody will help if you do not share your code and the parts that you think causes the issue