Root-cause work, not another guess. The esp_lcd DSI driver's own ISR says it:
// when an underrun happens, the LCD display may already becomes blue
ESP_DRAM_LOGE(TAG, "can't fetch data from external memory fast enough, ...")
A DSI bridge FIFO underrun displays as exactly one blue frame -- the reported
whole-screen split-second blue flash -- and the driver logs an error line every
time it happens. Every serial capture until now grepped for tile/storage/trace
patterns that this line does not match, so it was never looked for.
The esp-iot-solution MIPI-DSI guide prescribes, for this exact error: L2 cache
256 KB, 128 B cache lines, and perf optimization (plus SPIRAM 200M + XIP from
PSRAM, already set). Applied all three for this board only:
- build.sh: sdkconfig fragment order general;wadamesh;tdisplay_p4 so the BOARD
fragment wins over the shared ones (it was last-loser before; the shared
wadamesh fragment's -Os, needed for the Tanmatsu AppFS ceiling, was
unoverridable). No net config change from the reorder itself: the board
fragment previously duplicated no shared keys.
- sdkconfigs/tdisplay_p4: COMPILER_OPTIMIZATION_PERF, CACHE_L2_CACHE_256KB,
CACHE_L2_CACHE_LINE_128B. App 2.99 -> 3.35 MB of the 4 MB slot.
- main/CMakeLists.txt: -O2's deeper analysis trips new warnings in vendored
components (esp-modbus etc.); same keep-visible-never-fatal policy as the
existing strips.
Verification harness (scratchpad, not shipped): the companion protocol driven
over the USB console (contact add/remove = the 100% reported trigger, pure
local DB ops, no LoRa TX) while the same session captures every console line.
Since the driver logs each underrun unconditionally, one watched run now gives
a decisive verdict whichever way it goes.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
