3 Commits

Include renames

Author	SHA1	Message	Date
jpmschweitzerandClaude Opus 4.8	88a7f3e9cc	Lower DSI lane rate to 720 Mbps to smooth framebuffer reads ... The stock 1500 Mbps (the P4 maximum) makes the DSI transmit each line in a tight burst, so the framebuffer reads are bursty and lose the PSRAM bus to the Wi-Fi SDIO DMA under load. 720 spreads the read out and tolerates the contention. Espressif's documented underrun mitigation; the floor at this pixel clock is ~480 Mbps. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LKPbR6DY2JygHbyLjxm7Uu	2026-07-15 18:02:59 +02:00
jpmschweitzerandClaude Opus 4.8	67de636ab4	Fix DSI blue flicker under load: lower DPI clock to 40 MHz ... The blue flicker during voice activity is a MIPI-DSI framebuffer-read underrun on the PSRAM bus, not tearing. The DSI DMA reads the 800x800 framebuffer continuously (~138 MB/s at the stock 80 MHz clock); under load the Wi-Fi (esp-hosted SDIO) and audio-playback DMA on the same PSRAM bus starve the DSI FIFO, which the hardware then paints blue ("lcd.dsi.dpi: can't fetch data from external memory fast enough"). Drop the DPI pixel clock to 40 MHz (~54 fps): halves the continuous read and gives the FIFO slack to ride out bursty SDIO latency spikes. Still smooth for the face UI, and lowers display power. Vendored as a local component because managed_components/ is gitignored (same pattern as the esp_hosted fork) — a local component overrides the same-named waveshare/ managed dependency, so the fix survives a clean build. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LKPbR6DY2JygHbyLjxm7Uu	2026-07-15 14:41:34 +02:00
jpmschweitzerandClaude Fable 5	cb5826e02b	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>	2026-07-15 09:50:27 +02:00