ESP32-S3 CSI node firmware — fixes the #1135 phantom-LD2410 + sendto ENOMEM loop reported against v0.8.1-esp32.
Fixes (#1135)
- Phantom LD2410 on a floating UART (root cause). Probe-detection matched only the 4-byte head
0xF4F3F2F1, so line noise at 256000 baud on an unconnected UART1 could phantom-detect a sensor and spawn a UART task. Now requires a full validated report frame (head + sane intra-frame length + matching tail0xF8F7F6F5) — the same validate-before-trust gate used for MR60BHA2 in v0.8.1. Extracted tommwave_detect.hand covered by a host unit test (test_mmwave_detect.c). sendto ENOMEMstuck loop. The fixed 100 ms backoff was too short to drain sustained lwIP/WiFi buffer pressure. Now exponential (100→200→…→2000 ms per consecutive ENOMEM, reset on first successful send). Removing the phantom LD2410 task also removes the extra load that tipped tier-2 nodes into the stuck state.
Validation
- All CI green (firmware s3-8mb/4mb + c6, all QEMU configs, fuzzing, security scans).
- Host unit test: the #1135 case (head magic without valid tail) is REJECTED.
- Hardware (ESP32-S3 QFN56 rev v0.2): streams clean at tier-0 and tier-2, correctly reports no mmWave (no phantom), no regression.
- Caveat: the reporter's environment-specific floating-pin noise could not be reproduced on the bench, so the deterministic proof for the phantom case is the unit test. If you hit #1135, please confirm this build clears it.
Flashing (ESP32-S3)
esptool --chip esp32s3 -p <PORT> -b 460800 write_flash \
0x0 bootloader.bin 0x8000 partition-table.bin \
0xf000 ota_data_initial.bin 0x20000 esp32-csi-node-s3-8mb.bin
4MB boards: esp32-csi-node-s3-4mb.bin @ 0x20000, partition-table-4mb.bin @ 0x8000.
SHA-256
d1dd4143…ee24f7d esp32-csi-node-s3-8mb.bin
958fdd68…a686fcc esp32-csi-node-s3-4mb.bin
4c402ce4…714da509 bootloader.bin
67222c25…054d322b partition-table.bin
4c2cc4ff…e70d81f0 partition-table-4mb.bin
7d2c7ac4…3782c62f ota_data_initial.bin
App version 0.7.0 · ESP-IDF v5.4 · built from main @ 7831f29.