Root cause (verified against our exact IDF tree, not the community guess): the "258" in "sdio_write_task: Failed to send data: 258" is NOT a timeout (that is 263). 258 = 0x102 = ESP_ERR_INVALID_ARG. On the ESP32-P4, block- mode CMD53 writes require the SOURCE buffer to be 64-byte (cache-line) aligned; the IDF sdmmc driver rejects a misaligned source with INVALID_ARG BEFORE any bus activity. esp_hosts write loop then declares "Unrecoverable host sdio state" and reboots the whole P4. The audio TX payload is not 64-aligned, so streaming mic audio wedged on the very FIRST frame (which is exactly what we saw: listening -> instant Failed to send -> reboot). This also explains why buffer/queue/clock/retry tuning all did nothing: the write never reached the bus. And why our symptom was instant, not after ~100 writes (the community block-mode-desync theory) — it is the first misaligned buffer, every time. Fix: vendored esp_hosted 2.12.11 as an editable local component (overrides the registry copy) and bounce a misaligned TX payload through one aligned DMA scratch buffer in hosted_sdio_write_block (port_esp_hosted_host_sdio.c). TX is serialized by the bus lock so a single static bounce buffer is safe; freed in hosted_sdio_deinit. Host-only change — no C6 reflash. VERIFIED ON HARDWARE (autonomous self-test): 40s of continuous mic-audio upstream streaming — the traffic that previously wedged on the first frame — ran clean, zero timeouts, zero reboots. A guarded SDIO_TX_SELFTEST harness is kept (compiled out) for future SDIO stress testing. Credit: root cause + patch designed via multi-agent investigation; the precise 258=INVALID_ARG decode (correcting the upstream community timeout assumption) came from checking our actual esp_err.h. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2.5 KiB
2.5 KiB
ESP-Hosted-MCU Wi-Fi Design & Implementation details
Sequence Diagram for Wi-Fi communication
On a ESP chipset with native Wi-Fi, a Wi-Fi api call or network data from the application is processed internally on the chip and a Wi-Fi response is returned to the application.
sequenceDiagram
box rgb(128, 128, 128) Host With Native WI-Fi
participant app as Application
participant api as ESP-IDF Wi-Fi Library
participant wifi as Wi-Fi Hardware
end
app ->> api : esp_wifi_xxx() or Network Data
api ->> wifi :
Note over wifi : Do Wi-Fi action
wifi -->> api : Wi-Fi response or Data
api -->> app : Response or Network Data
Using Wi-Remote and ESP-Hosted, the Wi-Fi api call from the application is converted into a Hosted Call and transported to the slave. The slave converts the Hosted Call back into an Wi-Fi api call. The response (optionally with data) is converted into a Hosted Response and transported back to the host. On the host, the Hosted Response is converted back into a Wi-Fi response (optionally with data) is returned to the application.
For Network Data, Hosted does not do data conversion and only encapsulates the data for transport.
sequenceDiagram
box rgb(128, 128, 128) Host with ESP-Hosted
participant app as Application
participant remote as Wi-Fi Remote
participant hostedh as ESP-Hosted
participant transporth as Host Transport
end
box rgb(128, 128, 128) Slave ESP-Hosted
participant transports as Slave Transport
participant hosteds as Slave Hosted
participant api as ESP-IDF Wi-Fi Library
participant wifi as Wi-Fi Hardware
end
app ->> remote : esp_wifi_xxx()
remote ->> hostedh : esp_wifi_remote_xxx()
app ->> hostedh : Network Data
Note over hostedh : add Hosted header
hostedh ->> transporth :
transporth ->> transports : SPI/SDIO
transports ->> hosteds :
Note over hosteds : remove Hosted header
hosteds ->> api : esp_wifi_xxx()
hosteds ->> wifi : Network Data
api ->> wifi : Wi-Fi command or Data
Note over wifi: Do Wi-Fi action
wifi -->> api : Wi-Fi response or Data
wifi -->> hosteds : Network Data
api -->> hosteds : Response
Note over hosteds : add Hosted header
hosteds -->> transports :
transports -->> transporth : SPI/SDIO
transporth -->> hostedh :
Note over hostedh : remove Hosted header
hostedh -->> app : Network Data
hostedh -->> remote : Wi-Fi Command response
remote -->> app : Response