esp32 node crash

[1xhh1]

When connecting to the company's local area network (LAN), the ESP32 node program crashes. After checking the logs and troubleshooting, I found that the edge_dsp task is stuck in an infinite loop without releasing the CPU, causing the IDLE1 task to starve. Does this project have to collect data independently in a separate room? The version used is v0.5.0.

[2026-03-27 17:22:50.503]# RECV ASCII/320 <<<
E (498914) task_wdt: Task watchdog got triggered. The following tasks/users did not reset the watchdog in time:
E (498914) task_wdt: - IDLE1 (CPU 1)
E (498914) task_wdt: Tasks currently running:
E (498914) task_wdt: CPU 0: IDLE0
E (498914) task_wdt: CPU 1: edge_dsp
E (498914) task_wdt: Print CPU 1 backtrace

[2026-03-27 17:22:50.536]# RECV ASCII/190 <<<
Backtrace: 0x4037890F:0x3FC9D6A0 0x4037746D:0x3FC9D6C0 0x400559DD:0x3FCCA2A0 0x4037E96F:0x3FCCA2B0 0x40378965:0x3FCCA2D0 0x40378985:0x3FCCA2F0 0x4038074E:0x3FCCA310 0x4200D225:0x3FCCA330

[ruvnet]

Fix Released in v0.5.1

The edge_dsp watchdog crash has been fixed in v0.5.1-esp32 (PR #325).

Root Cause

On busy LANs (corporate networks with many APs), CSI callbacks fire at rates much higher than the expected 20 Hz. The edge_dsp task processed frames back-to-back with only 1-tick (10ms) yields between them, which wasn't enough to prevent IDLE1 starvation on Core 1 — triggering the 5-second task watchdog.

Fix

• Batch-limited processing: Now processes at most 4 frames before a 20ms yield, guaranteeing IDLE1 gets CPU time even under sustained load
• Fixed idle busy-spin: The previous vTaskDelay(pdMS_TO_TICKS(5)) evaluated to vTaskDelay(0) at 100Hz tick rate — effectively a busy-spin. Now uses vTaskDelay(1) for a proper tick delay
• Observability: Added drops=N counter in the periodic vitals log to diagnose frame loss

QEMU Validation

All 11 QEMU CI jobs pass: 7 firmware configs (default, edge-tier0, edge-tier1, tdm-3node, boundary-min/max, full-adr060) + fuzz testing + swarm test + NVS matrix + build.

CI Run — all green ✅

How to verify

Rebuild and reflash the firmware from main. Monitor serial output — you should no longer see task_wdt errors, and the drops= counter in vitals logs will show if any frames are being lost.