diag(P4): Schwarzes Bild eingrenzen - Prüfbild und lückenlose Meldungen (1.6.15)

Kaltstart, kein einziger Fehler im Log, alle I2C-Bausteine da - und trotzdem
keine Anzeige. Zwei Lücken in der Diagnose:

- Die DCS-Weckbefehle (MADCTL, Sleep Out, Display On) liefen ungeprüft
  durch. Jetzt über BSP_STEP gemeldet.
- Nach dem Panel-Start endete die Ausgabe. "Bringup fertig" vor und
  "LVGL laeuft" nach lvgl_port_init() trennen jetzt ein Hängenbleiben in
  LVGL von einem fehlenden Bild.

Neuer Schalter WS7_TEST_PATTERN nutzt esp_lcd_dpi_panel_set_pattern() für
Farbbalken aus dem DSI-Baustein, ohne Framebuffer und ohne LVGL - wie im
funktionierenden Werks-Testsketch. Erscheinen sie, arbeitet die Kette bis
zum Panel und der Fehler liegt weiter oben.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018QoLDQeUh1dCQz7yYZVb4Y

P4_Display_Firmware/Changelog.txt

@@ -1,3 +1,28 @@
+Version 1.6.15:
+- Diagnose fuer das schwarze Bild, das der Log bisher nicht erklaeren konnte: Alle Schritte
+  liefen fehlerfrei durch, trotzdem blieb die Anzeige leer.
+- Die drei Weckbefehle an das Panel (MADCTL, Sleep Out, Display On) liefen bislang
+  ungeprueft durch und sind jetzt in die Fehlerausgabe einbezogen.
+- Neuer Schalter WS7_TEST_PATTERN in pins_config.h: zeigt statt der Oberflaeche
+  Prueffarbbalken an. Sie entstehen im DSI-Baustein selbst und benutzen weder Bildspeicher
+  noch LVGL. Damit laesst sich in einem Durchgang trennen, ob die Anzeigekette bis zum
+  Panel arbeitet oder ob der Fehler weiter oben liegt.
+- Das Ende des Hochlaufs wird gemeldet ("Bringup fertig" / "LVGL laeuft"). Bisher endete
+  die Ausgabe nach dem Panel-Start, und ein Haengenbleiben in LVGL war von einem
+  fehlenden Bild nicht zu unterscheiden.
+
+Version 1.6.14:
+- Der Touch-Controller wird jetzt erst angesprochen, nachdem die Bridge freigegeben und die
+  Hintergrundbeleuchtung eingeschaltet ist. Der GT9271 haengt an derselben Versorgung und
+  antwortet vorher nicht auf I2C - deshalb schlug seine Initialisierung bisher schon beim
+  Kaltstart fehl. In der Werks-Testskizze steht die Touch-Initialisierung aus demselben
+  Grund hinter dem Einschalten der Beleuchtung; beim Uebertragen in die Firmware war diese
+  Reihenfolge verloren gegangen.
+- Die Wartezeit dazwischen steht als WS7_TOUCH_POWER_MS in pins_config.h (Vorgabe 120 ms).
+- Neu im Start-Log: eine Liste aller Bausteine am I2C-Bus, einmal vor und einmal nach dem
+  Panel-Start. Erwartet werden 0x45 (Bridge) und 0x14 (Touch). Damit ist auf einen Blick zu
+  sehen, ob ein Baustein gar nicht antwortet, statt aus Treiberfehlern raten zu muessen.
+
 Version 1.6.13:
 - Ursache des schwarzen Bildes gefunden: ein haengender I2C-Bus. Trifft ein Reset des P4
   mitten in eine laufende Uebertragung, bleibt der angesprochene Baustein in seiner

P4_Display_Firmware/board_bringup.c

@@ -131,6 +131,20 @@ static void ws7_i2c_bus_recover(void)
     gpio_reset_pin(BSP_I2C_SDA);
     gpio_reset_pin(BSP_I2C_SCL);
 }
+
+// Zeigt, welche Bausteine sich am I2C-Bus melden. Erwartet werden 0x45 (Bridge) und
+// 0x14 (GT9271-Touch); 0x18 waere der Audio-Baustein. Fehlt einer, sagt das mehr aus als
+// jede Fehlermeldung des Treibers.
+static void ws7_i2c_scan(const char *wann)
+{
+    esp_rom_printf("[Panel] I2C-Bausteine (%s):", wann);
+    for (uint8_t addr = 1; addr < 127; addr++) {
+        if (i2c_master_probe(s_i2c_handle, addr, 50) == ESP_OK) {
+            esp_rom_printf(" 0x%02X", addr);
+        }
+    }
+    esp_rom_printf("\n");
+}
 #endif  // JC_PANEL_TYPE == WS_PANEL_7H
 
 // Klartext-Meldung auf der seriellen Konsole. Bewusst esp_rom_printf: das laeuft auch bei
@@ -389,6 +403,7 @@ bool jc_board_bringup(void)
     i2c_new_master_bus(&i2c_bus_conf, &s_i2c_handle);
 
 #if JC_PANEL_TYPE == WS_PANEL_7H
+    ws7_i2c_scan("vor dem Panel-Start");
     // Bridge des Waveshare-Panels vorbereiten (noch ohne Hintergrundbeleuchtung).
     ws7_bridge_pre_init();
 #endif
@@ -471,13 +486,23 @@ bool jc_board_bringup(void)
     {
         uint8_t zero = 0x00;
         uint8_t madctl = WS7_MADCTL;
-        esp_lcd_panel_io_tx_param(io, 0x36, &madctl, 1); // MADCTL
-        esp_lcd_panel_io_tx_param(io, 0x11, &zero, 1);   // Sleep Out
+        BSP_STEP(esp_lcd_panel_io_tx_param(io, 0x36, &madctl, 1), "Panel-Befehl MADCTL");
+        BSP_STEP(esp_lcd_panel_io_tx_param(io, 0x11, &zero, 1), "Panel-Befehl Sleep Out");
         vTaskDelay(pdMS_TO_TICKS(120));
-        esp_lcd_panel_io_tx_param(io, 0x29, &zero, 1);   // Display On
+        BSP_STEP(esp_lcd_panel_io_tx_param(io, 0x29, &zero, 1), "Panel-Befehl Display On");
         vTaskDelay(pdMS_TO_TICKS(20));
     }
     BSP_STEP(esp_lcd_panel_init(disp_panel), "DPI-Videoausgabe starten");
+#if WS7_TEST_PATTERN
+    // Prueffarbbalken: Sie entstehen im DSI-Baustein selbst und benutzen weder den
+    // Bildspeicher noch LVGL. Erscheinen sie, arbeitet die gesamte Anzeigekette bis zum
+    // Panel korrekt und der Fehler liegt weiter oben (Bildspeicher, LVGL, Oberflaeche).
+    // Bleibt das Bild schwarz, liegt es an DSI, Zeitbasis oder Panel.
+    BSP_STEP(esp_lcd_dpi_panel_set_pattern(disp_panel, MIPI_DSI_PATTERN_BAR_VERTICAL),
+             "Prueffarbbalken");
+    esp_rom_printf("[Panel] Pruefbild aktiv - erwartet werden senkrechte Farbbalken.\n");
+#endif
+
 #elif JC_PANEL_TYPE == JC_PANEL_70
     // ---------------- 7,0" JD9165 (1024x600) ----------------
     esp_lcd_dsi_bus_config_t bus_config = JD9165_PANEL_BUS_DSI_2CH_CONFIG();
@@ -567,6 +592,16 @@ bool jc_board_bringup(void)
     };
     esp_lcd_dpi_panel_register_event_callbacks(disp_panel, &cbs, NULL);
 
+#if JC_PANEL_TYPE == WS_PANEL_7H
+    // Bridge freigeben und Beleuchtung einschalten, BEVOR der Touch angesprochen wird.
+    // Der GT9271 antwortet erst danach: Die Freigabe der Bridge (Register 0xAD) versorgt
+    // offenbar auch ihn. In der Werks-Testskizze steht die Touch-Initialisierung aus
+    // demselben Grund hinter dem Einschalten der Beleuchtung.
+    jc_backlight_set(100);
+    vTaskDelay(pdMS_TO_TICKS(WS7_TOUCH_POWER_MS));
+    ws7_i2c_scan("nach dem Panel-Start");
+#endif
+
     esp_lcd_panel_io_handle_t tp_io_handle = NULL;
     // MUSS vorbelegt sein: schlaegt die Touch-Initialisierung fehl, gibt der Treiber einen
     // unbrauchbaren Zeiger zurueck. Ohne Vorbelegung landet Muell im LVGL-Port.
@@ -613,7 +648,9 @@ bool jc_board_bringup(void)
     lvgl_port_interface_t interface =
         (dpi_config.flags.use_dma2d) ? LVGL_PORT_INTERFACE_MIPI_DSI_DMA
                                      : LVGL_PORT_INTERFACE_MIPI_DSI_NO_DMA;
+    esp_rom_printf("[Panel] Bringup fertig - LVGL wird gestartet\n");
     lvgl_port_init(disp_panel, tp_handle, interface);
+    esp_rom_printf("[Panel] LVGL laeuft\n");
     return true;
 }
 

P4_Display_Firmware/pins_config.h

@@ -140,6 +140,16 @@
 // Wert verzoegert das Loslassen und daempft dadurch den Schwung beim Wischen.
 #define WS7_TOUCH_HOLD_MS 40
 
+// Wartezeit zwischen dem Freigeben der Bridge und dem Ansprechen des Touch. Der GT9271
+// haengt an derselben Versorgung und braucht nach dem Einschalten einen Moment, bis er
+// auf I2C antwortet. Meldet sich 0x14 beim Start nicht, diesen Wert erhoehen.
+#define WS7_TOUCH_POWER_MS 120
+
+// Prueffarbbalken statt Oberflaeche anzeigen. Sie entstehen im DSI-Baustein selbst und
+// benutzen weder Bildspeicher noch LVGL. Damit laesst sich trennen, ob die Anzeigekette
+// bis zum Panel arbeitet (Balken sichtbar) oder nicht (schwarz). Nur zur Fehlersuche.
+#define WS7_TEST_PATTERN 0
+
 #elif JC_PANEL_TYPE == JC_PANEL_70
 
 #define LCD_H_RES 1024