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>
About Proto Files
Protobuf Submodule
protobuf-c is open source code used as submodule in ESP-Hosted-FG in directory ../protobuf-c/
If this directory is empty, please run
$ cd esp-hosted
$ git submodule update --init --recursive
Files
-
esp_hosted_rpc.proto- This is Ready-To-Use protobuf file which has messages for Request / Response / Events to communicate between Host and ESP
- User can add his own message field in
.protofile and generate respective C files using 'protoc'
-
esp_hosted_rpc.pb-c.c&esp_hosted_rpc.pb-c.h- Ready-To-Use Source Generated files using
esp_hosted_rpc.proto - These files also cached which was generated with current
esp_hosted_rpc.protofile for easy use (No need to generate again) - If any addition or modifications
esp_hosted_rpc.protodone, these files need to be re-generated
- Ready-To-Use Source Generated files using
Generate esp_hosted_rpc.pb-c.c & esp_hosted_rpc.pb-c.h
If you want to add or modify existing set of RPC procedures supported, you need to modify esp_hosted_rpc.proto as needed and build it to generate new set of esp_hosted_rpc.pb-c.c & esp_hosted_rpc.pb-c.h.
For this, third party software for protobuf C compiler is needed to be installed
- Debian/Ubuntu
- sudo apt install protobuf-c-compiler
- Mac OS
- brew install protobuf protobuf-c
- Windows
protoc --c_out always needs the protoc-gen-c plugin from protobuf-c, so both protoc and protobuf-c must be present (on macOS these are separate Homebrew formulas, hence both are listed above).
This software might only be needed on development environment, Once esp_hosted_rpc.pb-c.c & esp_hosted_rpc.pb-c.h files are generated, could also be uninstalled (no more needed).
Steps to generate
$ cd <path/to/esp_hosted_fg>/common/proto
$ protoc esp_hosted_rpc.proto --c_out=.
Add new RPC message
To send an new RPC request/response
- Add C function in
host/host_common/commands.c - Create python binding in
host/linux/host_control/python_support/commands_map_py_to_c.pyand its python function inhost/linux/host_control/python_support/commands_lib.py. - Add ESP side C function in
esp/esp_driver/network_adapter/main/slave_commands.c, respective to python function, to handle added message field.
User can test added functionality using host/linux/host_control/python_support/test.py.