diff --git a/tdisplay_p4/main/CMakeLists.txt b/tdisplay_p4/main/CMakeLists.txt
index 2b47f75..5c5c6dd 100644
--- a/tdisplay_p4/main/CMakeLists.txt
+++ b/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)")
diff --git a/tdisplay_p4/sdkconfigs/tdisplay_p4 b/tdisplay_p4/sdkconfigs/tdisplay_p4
index 60eb6f8..44becbc 100644
--- a/tdisplay_p4/sdkconfigs/tdisplay_p4
+++ b/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