Persistent sendto ENOMEM on ESP32-S3 N16R8 (AMOLED board) — zero UDP frames reach server, not fixed by --edge-tier 1 (v0.8.8-esp32)

Summary

On two separate ESP32-S3 boards (both N16R8, 16MB flash / 8MB PSRAM, Waveshare-style with SH8601 AMOLED detected at boot), the v0.8.8-esp32 firmware produces continuous sendto ENOMEM from within seconds of boot. The server receives zero CSI frames — Frames Processed: 0 and no UDP receive logs at all.

Unlike #683, switching to --edge-tier 1 did not help; the ENOMEM pattern is essentially identical.

Environment

• Board: ESP32-S3 N16R8 (16MB flash / 8MB PSRAM), AMOLED SH8601 368x448 detected, FT3168 touch not found (runs headless)
• Chip: ESP32-S3 (QFN56) rev v0.2
• Firmware: v0.8.8-esp32 (esp32-csi-node-v0.8.8-s3-8mb-flash-bundle)
• Host: macOS, server built from source (cargo run -p wifi-densepose-sensing-server)
• Server flags: --http-port 3000 --ws-port 3001 --bind-addr 0.0.0.0 --udp-bind 0.0.0.0 --udp-insecure-lan --source esp32
• WiFi: 2.4GHz, RSSI around -33 to -55 dBm (good signal)
• Tested on two different boards — identical behavior, so not a single-unit defect.

What works

• WiFi connects successfully
• CSI streaming active → 192.168.0.66:5005 is logged
• CSI callbacks fire normally (csi_collector: CSI cb #1400: len=384 rssi=-47 ch=1)
• Server shows "Real hardware connected" / Source: esp32 in the UI

What fails

Nearly every sendto fails with ENOMEM, so no frames actually leave the device.

Serial log (edge-tier 2, default)

W (16249) stream_sender: sendto ENOMEM — backing off for 2000 ms (streak 9)
W (16289) stream_sender: sendto suppressed (ENOMEM backoff, 1 dropped)
I (16629) adaptive_ctrl: medium tick: state=5 yield=31pps dsp=14.6Hz motion=0.00 presence=0.00 rssi=-43
W (16629) adaptive_ctrl: feature_state emit failed
...
W (24279) stream_sender: sendto ENOMEM — backing off for 2000 ms (streak 13)

Streak reaches 16+ within a few minutes. motion and presence stay at 0.00 throughout.

Serial log (after --edge-tier 1)

W (47099) stream_sender: sendto ENOMEM — backing off for 100 ms (streak 1)
W (47239) stream_sender: sendto ENOMEM — backing off for 200 ms (streak 2)
W (47479) stream_sender: sendto ENOMEM — backing off for 400 ms (streak 3)
W (47889) stream_sender: sendto ENOMEM — backing off for 800 ms (streak 4)
W (48739) stream_sender: sendto ENOMEM — backing off for 1600 ms (streak 5)
W (50349) stream_sender: sendto ENOMEM — backing off for 2000 ms (streak 6)

Same pattern — the --edge-tier 1 workaround from #683 does not resolve it here.

Server side

The server logs show only WebSocket client connect/disconnect. There is no UDP receive activity at all:

INFO sensing_server: UDP listening on 0.0.0.0:5005 for ESP32, MediaTek, Qualcomm CSI, and RTL8720F radar frames
INFO sensing_server: WebSocket client connected (sensing)
INFO sensing_server: WebSocket client connected (pose)

Question

ADR-045 notes that "SPIRAM was disabled in sdkconfig despite hardware having 8MB PSRAM". Could the lwIP buffer exhaustion here be caused by the released s3-8mb binary not enabling PSRAM on N16R8 boards? Is there a recommended sdkconfig change or an alternative build for this board variant?

Start with ADR-045 and the released s3-8mb binary's sdkconfig, then inspect the stream_sender ENOMEM/backoff path and compare the edge-tier 2 and 1 logs. Reproduce on an ESP32-S3 N16R8 with the stated server flags; done means identifying whether PSRAM or configuration causes the failure and confirming UDP CSI frames reach the server, or documenting an alternative build.