Fork fix: the SDIO wedge is FIXED (esp-hosted-mcu #167)
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>
This commit is contained in:
@@ -0,0 +1,31 @@
|
||||
| Supported Hosts | ESP32-P4 |
|
||||
| --------------- | -------- |
|
||||
|
||||
| Supported Co-processors | ESP32-C5 | ESP32-C6 |
|
||||
| ----------------------- | -------- | -------- |
|
||||
|
||||
# Wifi itwt Example
|
||||
|
||||
## Introduction
|
||||
This example shows how to use itwt of wifi.
|
||||
|
||||
Itwt only works in station mode. And AP needs to support the capability of itwt.
|
||||
|
||||
Itwt can works under different power save mode.
|
||||
|
||||
### Modem sleep (supported)
|
||||
This is default mode. Under this mode, can support console command "itwt, probe" to config itwt.
|
||||
|
||||
* itwt: this command is for itwt setup/teardown/suspend.
|
||||
* probe: this command will send a probe request to update tsf time with ap
|
||||
|
||||
### Light Sleep (will support)
|
||||
Need system support light sleep. Console command will not support in this mode.
|
||||
|
||||
### Typical current consumption with Itwt enabled
|
||||
|
||||
|
||||
### Typical current consumption with Itwt disabled
|
||||
|
||||
|
||||
Note that current consumption and average current are higher when disabled.
|
||||
Reference in New Issue
Block a user