p4: flush-trace build gate + take code/rodata off the PSRAM bus (#167)

Ran the flush tracer instead of theorising further. Result is decisive: every
large uniform band LVGL pushes to the panel is rgb565=0x0000 (black), across the
whole boot window where the flash occurs. LVGL never paints the flash colour, so
the panel is displaying something that was never written to the framebuffer.
That excludes the entire UI layer, and with it the redraw/repaint theories.

Adds WADA_P4_FLUSH_TRACE=1 as a build gate so the tracer can be run on demand
without shipping it (it slows the flush path, so never confirm a fix with it on).

With the UI excluded the remaining candidate is the DSI starving. The panel
streams ~84 MB/s out of PSRAM continuously, and XIP put every instruction fetch
and rodata read on that same bus. The triggers are all bursts of code and data
churn (rebuilding the contact/chat list); panning the map reuses a warm tile
cache and never flashes. Turning XIP off leaves the PSRAM bus essentially to the
display. Experiment, not a claimed fix.

Also supersedes the burst-count theory from 1e6e121: widening LVGL bands from 24
to 64 lines (26 transfers -> 10 for a full repaint) changed nothing on device.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

tdisplay_p4/main/CMakeLists.txt

@@ -111,6 +111,14 @@ endforeach()
 # One-off C6-reflash helper: build with `C6_FLASH_HELPER=1 ./build.sh build` to boot a P4 image that
 # never touches the C6 (no C6_EN reset pulse, no AT worker), so the C6 can be held in ROM download mode
 # and reflashed over its own USB. Harmless when the env var is unset (normal builds are unaffected).
+# Diagnostic build for the whole-screen colour flash (#167): `WADA_P4_FLUSH_TRACE=1 ./build.sh build`
+# logs every large, mostly-single-colour band pushed to the panel, with its RGB565 value. If the
+# screen flashes and nothing logs, the cause is below LVGL and the UI is the wrong place to look.
+if(DEFINED ENV{WADA_P4_FLUSH_TRACE})
+  idf_build_set_property(COMPILE_OPTIONS "-DTDP4_FLUSH_TRACE=1" APPEND)
+  message(STATUS "wadamesh: FLUSH TRACE enabled (diagnostic build, do not ship)")
+endif()
+
 if(DEFINED ENV{C6_FLASH_HELPER})
   idf_build_set_property(COMPILE_OPTIONS "-DTDP4_C6_FLASH_HELPER=1" APPEND)
   message(STATUS "wadamesh: BUILDING C6-FLASH HELPER (P4 leaves the C6 free)")

tdisplay_p4/sdkconfigs/tdisplay_p4

@@ -80,3 +80,15 @@ CONFIG_SPIRAM_XIP_FROM_PSRAM=y
 # inherit a bogus GPIO reset.
 CONFIG_ESP_HOSTED_RESET_SLAVE_USING_CALLBACK=y
 CONFIG_ESP_HOSTED_SDIO_RESET_SLAVE_USING_CALLBACK=y
+
+# --- #167 whole-screen colour flash: keep code/rodata OFF the PSRAM bus. ------------------------
+# The flush tracer proved LVGL never paints the flash colour (every large band it pushes is 0x0000
+# black), so the panel is displaying something that was never in the framebuffer -- i.e. the DSI is
+# starving, not the UI misdrawing. This panel streams 568*1232*2 bytes ~60x/s = ~84 MB/s out of
+# PSRAM continuously, and with XIP every instruction fetch and rodata read competes for that same
+# bus. The reported triggers are all bursts of code + data churn (rebuilding the contact/chat list),
+# while panning the map reuses a warm tile cache and never flashes. Turning XIP off leaves the PSRAM
+# bus essentially to the display alone; code runs from flash through the cache as usual.
+CONFIG_SPIRAM_FETCH_INSTRUCTIONS=n
+CONFIG_SPIRAM_RODATA=n
+CONFIG_SPIRAM_XIP_FROM_PSRAM=n