v0.6.5-esp32: stack overflow in swarm task during Seed TLS init - firmware-direct ingest unusable

[marfleetn]

On v0.6.5-esp32, enabling the firmware's direct-to-Seed ingest (provisioning --seed-url / --seed-token) causes the swarm task to overflow its stack immediately after it initialises - right where it would open the HTTPS/TLS connection to the Seed. The node panics and reboots, looping on every boot.

Everything else in the firmware runs cleanly on the same boot - WiFi, CSI capture, edge DSP at tier 2, UDP streaming, display init - so this is specific to the swarm task, not a board or general-config problem.

This looks like the same class of bug as the Tmr Svc stack overflow fixed in this release (undersized FreeRTOS task stack), but in the swarm task.

Environment

• Firmware: v0.6.5-esp32, 8 MB variant (esp32-csi-node.bin). Boot log: App version: 0.6.5, Compile time: May 18 2026.
• Board: ESP32-S3, 16 MB flash + 8 MB PSRAM (N16R8-class), chip rev v0.2. The 8 MB image runs fine here (Detected size 16384k … using image header 8192k).
• Flash: esptool 5.3.0, matched set at 0x0 / 0x8000 / 0xf000 / 0x20000, --flash_mode dio --flash_size 8MB.
• Provisioning: provision.py with --edge-tier 2 and the swarm flags (--seed-url, --seed-token, --zone, --swarm-hb 30, --swarm-ingest 5).

Steps to reproduce

1. Flash the v0.6.5 8 MB matched set.
2. Provision with swarm enabled:

   provision.py --port COMx --chip esp32s3 --ssid … --password … \
     --node-id 1 --zone GND-LIVING --target-ip 192.168.1.236 --target-port 5006 \
     --seed-url https://192.168.1.236:8443 --seed-token <token> \
     --swarm-hb 30 --swarm-ingest 5 --edge-tier 2
   

3. Reset and watch serial. The node connects to WiFi, starts CSI/edge DSP, then the swarm bridge inits and panics within ~1 s.

Expected vs actual

• Expected: the swarm task POSTs feature vectors to the Seed's /api/v1/store/ingest.
• Actual: stack overflow in the swarm task → panic → reboot, on every boot.

Log

I (4066) swarm: Bearer token configured for Seed auth
I (4066) swarm: bridge init OK - seed=https://192.168.1.236:8443 zone=GND-LIVING h…
***ERROR*** A stack overflow in task swarm has been detected.

Backtrace: 0x40375d41:0x3fcd3910 0x4037eac9:0x3fcd3930 0x4037f7c6:0x3fcd3950 0x40380d87:0x3fcd39d0 0x4037f90c:0x3fcd39f0 0x4037f902:0xa5a5a5a5 |<-CORRUPTED

Rebooting...
rst:0xc (RTC_SW_CPU_RST),boot:0x8 (SPI_FAST_FLASH_BOOT)

The 0xa5a5a5a5 tail is the FreeRTOS stack-fill pattern - the task exhausted its stack.

Suspected cause

The swarm task's stack appears too small for the mbedTLS handshake to the Seed (HTTPS), so it overflows as soon as it opens the TLS connection. This mirrors the Tmr Svc fix in the v0.6.5 notes (CONFIG_FREERTOS_TIMER_TASK_STACK_DEPTH=8192).

My workaround

Provision without --seed-url / --seed-token (Swarm bridge disabled (no seed_url configured)). Using the laptop as the bridge, the node is then stable and streams CSI over UDP; ingest into the Seed via a host-side UDP → /api/v1/store/ingest bridge.

[ruvnet]

The diagnosis is correct — the swarm task stack is too small to accommodate the mbedTLS handshake stack frames required to open an HTTPS connection to the Seed. The 0xa5a5a5a5 canary confirms the task exhausted its allocation before TLS negotiation completed.

This is the same class of issue as the v0.6.5 Timer Service fix (CONFIG_FREERTOS_TIMER_TASK_STACK_DEPTH=8192). The fix is to increase the swarm task's stack depth in sdkconfig / sdkconfig.defaults.

Suggested fix direction: search sdkconfig.defaults (and sdkconfig.defaults.template) for SWARM_TASK_STACK or the task's xTaskCreatePinnedToCore call in swarm_bridge.c and increase the stack size — mbedTLS typically needs ~8–12 KB of stack for a full TLS 1.2/1.3 handshake. Starting at 12288 (12 KB) and adjusting down should resolve the overflow.

Your workaround (host-side UDP → /api/v1/store/ingest bridge) is valid for the meantime and avoids the TLS path in firmware entirely.

---

Generated by Claude Code

[ruvnet]

Fixed in c353255 — merged to main as part of PR #975.

SWARM_TASK_STACK in firmware/esp32-csi-node/main/swarm_bridge.c bumped from 3072 → 8192 to fit the mbedTLS handshake. The original 3 KB was sized for plain HTTP ("~2.5 KB" per the original comment) which is fine for HTTP, far too small for TLS — mbedTLS handshake alone wants 4–6 KB (cipher suite + cert chain + ECDH state) plus another ~1.5-2 KB for esp_http_client. The 5 KB extra heap cost is negligible against the C6's RAM budget.

Couldn't reproduce live in the lab because the Seed URL wasn't provisioned on either of our boards, but the size math checks out against mbedTLS's stack analyzer and the build is clean. If you flash a build from main and still hit the panic, please re-open with the new backtrace.

[marfleetn]

Many thanks will try it out tomorrow.