fix(P4): Bridge-Grundeinstellung nach dem DSI-Start wiederholen (1.6.20)

Beobachtung am Gerät: Beim Einschalten geht nach 2-3 s die Beleuchtung an,
dann kommt nichts. Nach einem Reset geht die Beleuchtung kurz aus, danach
erscheint Beleuchtung samt Bild - reproduzierbar in zwei von zwei Fällen.

Dass die Beleuchtung ausgeht, zeigt: Die Bridge folgt dem DSI-Signal. Und
dass der zweite Durchlauf klappt, zeigt warum - die Bridge hatte ihre
Grundeinstellung aus dem ersten Durchlauf noch und fand diesmal ein
DSI-Signal vor. Beim ersten Start bekommt sie ihre Einstellung dagegen,
bevor die DSI-Strecke überhaupt existiert.

ws7_bridge_core_init() ist aus ws7_bridge_pre_init() herausgelöst und wird
jetzt ein zweites Mal aufgerufen, sobald esp_lcd_panel_init() läuft -
dasselbe Vorgehen wie bei ws7_panel_wake() in 1.6.19. Die Register sind
wiederholbar.

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

P4_Display_Firmware/Changelog.txt

@@ -1,3 +1,83 @@
+Version 1.6.20:
+- Nach 1.6.19 lief es reproduzierbar so ab: Beim Einschalten ging nach zwei bis drei
+  Sekunden die Hintergrundbeleuchtung an, dann kam nichts mehr; nach einem Reset ging die
+  Beleuchtung kurz aus und danach erschien Beleuchtung samt Bild. Daraus folgt der letzte
+  fehlende Schritt: Auch die Grundeinstellung der Bridge lief bisher nur einmal, und zwar
+  bevor die DSI-Strecke ueberhaupt existierte. Beim Reset half es nur deshalb, weil die
+  Bridge ihre Einstellung aus dem vorigen Durchlauf noch hatte und diesmal ein DSI-Signal
+  vorfand.
+- Die Grundeinstellung der Bridge wird jetzt ein zweites Mal geschrieben, sobald die
+  Videoausgabe laeuft - dasselbe Vorgehen wie bei den Weckbefehlen des Panels in 1.6.19.
+  Damit wird ohne Reset erreicht, was vorher erst der zweite Durchlauf brachte.
+- Im Start-Log sind beide Durchgaenge benannt ("Bridge-Grundeinstellung vor dem DSI-Start"
+  und "... nach dem Start der Videoausgabe").
+
+Version 1.6.19:
+- Die Wartezeit aus 1.6.18 hat den Start deutlich verbessert, aber noch nicht zuverlässig
+  gemacht. Aus dem verbliebenen Fehlerbild folgt der nächste Schritt: Die Beleuchtung ging
+  an, das Bild fehlte. Die Beleuchtung hängt an der Bridge und wird über I2C geschaltet -
+  sie funktioniert also. Verloren gehen die Weckbefehle an das Panel selbst.
+- Diese Befehle wurden bisher genau einmal geschickt, bevor die Videoausgabe lief. War der
+  Panel-Controller in dem Moment noch nicht aufnahmebereit, waren sie weg, und danach hat
+  nie wieder jemand nachgefragt. Sie werden jetzt ein zweites Mal gesendet, sobald die
+  Videoausgabe steht. Die Befehle sind wiederholbar, der zweite Anlauf kostet nichts.
+- Die Pause dazwischen steht als WS7_PANEL_SETTLE_MS in pins_config.h (Vorgabe 200 ms).
+- Im Start-Log ist jeder Anlauf einzeln zu sehen ("Weckbefehle vor/nach dem Start der
+  Videoausgabe").
+
+Version 1.6.18:
+- Ursache des unzuverlässigen Starts gefunden: Der P4 sprach Bridge und Panel sofort nach
+  dem Einschalten an. Das Displaymodul braucht danach aber einen Moment, bis es bereit ist.
+  Kam der Hochlauf zu früh, nahm die Bridge ihre Register nicht an oder das Panel zeigte
+  trotz korrekt gesendeter DSI-Daten nichts - beides ohne Fehlermeldung, weil aus Sicht des
+  P4 jeder Schritt geklappt hatte. Das Ergebnis war ein Display, das mal ansprang und mal
+  nicht, und beim ersten Anstecken meist gar nicht.
+- Der Hochlauf wartet jetzt WS7_PANEL_WARMUP_MS (Vorgabe 2000 ms), bevor er beginnt. Der
+  Werks-Testsketch wartet aus demselben Grund 2 Sekunden am Anfang.
+- Damit erklärt sich auch, warum es mit geöffnetem seriellen Monitor fast immer klappte:
+  Dessen USB-Anmeldung verzögert den Start und ersetzte damit unbeabsichtigt die Wartezeit.
+- Der Wert steht in pins_config.h. Läuft der Start zuverlässig, lässt er sich vorsichtig
+  senken; springt die Anzeige nicht an, ist er der erste Wert zum Erhöhen.
+
+Version 1.6.17:
+- Der I2C-Stoerimpulsfilter aus 1.6.16 wirkt: Nach dem Panel-Start melden sich wieder alle
+  drei Bausteine, Bridge und Touch bleiben ansprechbar.
+- Das Pruefbild aus 1.6.15 war allerdings wirkungslos und damit als Test untauglich: Es
+  wurde zwar gesetzt, doch unmittelbar danach startete LVGL und schrieb in den Bildspeicher,
+  womit das Pruefbild wieder verschwand. Der Test sah deshalb genauso aus wie der Fehler,
+  den er finden sollte.
+- Mit WS7_TEST_PATTERN = 1 endet der Hochlauf jetzt direkt nach dem Pruefbild: Beleuchtung
+  an, Farbbalken stehen, kein LVGL. Damit ist die Frage eindeutig zu beantworten, ob die
+  Anzeigekette bis zum Panel arbeitet.
+
+Version 1.6.16:
+- Ursache des schwarzen Bildes gefunden. Der Start-Log zeigte es eindeutig: Vor dem
+  Panel-Start meldeten sich alle drei I2C-Bausteine (Touch 0x14, Audio 0x18, Bridge 0x45),
+  danach nur noch der Audio-Baustein. Es fielen also genau die beiden weg, die am
+  Displaykabel haengen - der Bus selbst arbeitete weiter. Sobald die DSI-Ausgabe laeuft,
+  stoeren deren schnelle Signale auf das lange Flachbandkabel ein, und ohne Filterung
+  bringen diese Stoerspitzen die I2C-Uebertragung aus dem Tritt. Die Bridge liess sich
+  daraufhin nicht mehr ansprechen, das Panel blieb dunkel.
+- Der I2C-Bus laeuft fuer das Waveshare-Panel jetzt mit Stoerimpulsfilter und internen
+  Abschlusswiderstaenden, so wie es auch das Waveshare-Beispiel tut. Beides fehlte, weil
+  die Bus-Einrichtung urspruenglich von den JC-Panels uebernommen wurde, die kein
+  Flachbandkabel dieser Laenge haben.
+- Das erklaert rueckwirkend auch, warum sich der Fehler so sprunghaft verhielt: Ob eine
+  Uebertragung durchkam, hing von der Stoerlage ab.
+
+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

P4_Display_Firmware/board_bringup.c

@@ -193,8 +193,24 @@ static void ws7_bridge_write(uint8_t reg, uint8_t value)
     }
 }
 
-// Bridge am I2C-Bus anmelden und Grundinitialisierung schreiben. Muss VOR dem
-// DSI-Bringup laufen; die Hintergrundbeleuchtung bleibt dabei noch aus.
+// Grundeinstellung der Bridge. Bewusst mehrfach aufrufbar, siehe unten.
+//
+// Warum zweimal: Beim ersten Aufruf existiert die DSI-Strecke noch gar nicht - die Bridge
+// bekommt ihre Einstellung also, bevor ein Signal anliegt. Beim ersten Einschalten reichte
+// das nicht: Die Beleuchtung ging an (die haengt an der Bridge), ein Bild kam aber nicht.
+// Erst ein Reset half - und dann nur deshalb, weil die Bridge ihre Einstellung aus dem
+// vorigen Durchlauf noch hatte und diesmal ein DSI-Signal vorfand. Genau das holt der
+// zweite Aufruf nach, ohne dass ein Reset noetig ist. Die Register sind wiederholbar.
+static void ws7_bridge_core_init(const char *wann)
+{
+    esp_rom_printf("[Panel] Bridge-Grundeinstellung %s\n", wann);
+    ws7_bridge_write(0xC0, 0x01);
+    ws7_bridge_write(0xC2, 0x01);
+    ws7_bridge_write(0xAC, 0x01);
+}
+
+// Bridge am I2C-Bus anmelden und erstmalig einstellen. Laeuft VOR dem DSI-Bringup;
+// die Hintergrundbeleuchtung bleibt dabei noch aus.
 static void ws7_bridge_pre_init(void)
 {
     i2c_device_config_t dev_cfg = {
@@ -206,9 +222,7 @@ static void ws7_bridge_pre_init(void)
         s_bridge_handle = NULL;
         return;
     }
-    ws7_bridge_write(0xC0, 0x01);
-    ws7_bridge_write(0xC2, 0x01);
-    ws7_bridge_write(0xAC, 0x01);
+    ws7_bridge_core_init("vor dem DSI-Start");
 }
 
 void jc_backlight_init(void)
@@ -383,11 +397,50 @@ static void jc_touch_scale(esp_lcd_touch_handle_t tp, uint16_t *x, uint16_t *y,
 }
 #endif
 
+#if JC_PANEL_TYPE == WS_PANEL_7H
+// Panel wecken. Bewusst mehrfach, siehe unten.
+//
+// Ein reines DPI-Panel kennt keine reset-Funktion, esp_lcd_panel_reset() wuerde ins Leere
+// greifen - deshalb nur die DCS-Befehle.
+//
+// Warum mehrfach: Verpasst der Panel-Controller diese Befehle, weil er nach dem
+// Einschalten noch nicht bereit war, bleibt der Bildschirm dunkel, obwohl der P4 alles
+// korrekt gesendet hat und jeder Schritt Erfolg meldet. Die Hintergrundbeleuchtung geht
+// trotzdem an, weil sie an der Bridge haengt und nicht am Panel - genau dieses Bild.
+// Die Befehle sind wiederholbar, ein zweiter Anlauf nach dem Start der Videoausgabe
+// kostet nichts und faengt den Fall ab.
+static void ws7_panel_wake(esp_lcd_panel_io_handle_t io, const char *wann)
+{
+    uint8_t zero = 0x00;
+    uint8_t madctl = WS7_MADCTL;
+    esp_rom_printf("[Panel] Weckbefehle %s\n", wann);
+    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));
+    BSP_STEP(esp_lcd_panel_io_tx_param(io, 0x29, &zero, 1), "Panel-Befehl Display On");
+    vTaskDelay(pdMS_TO_TICKS(20));
+}
+#endif
+
 // Bringt Panel + Touch + LVGL-Port hoch (LVGL laeuft danach in eigenem Task).
 // Rueckgabe false: Panel kam nicht hoch - der Aufrufer darf dann KEINE LVGL-Funktion
 // benutzen, sonst folgt ein zweiter Absturz, der die eigentliche Ursache ueberdeckt.
 bool jc_board_bringup(void)
 {
+#if JC_PANEL_TYPE == WS_PANEL_7H
+    // Anlaufzeit abwarten, BEVOR Bridge und Panel angesprochen werden.
+    //
+    // Das Displaymodul braucht nach dem Anlegen der Versorgung einen Moment, bis Bridge
+    // und Panel bereit sind. Faengt der P4 sofort an, laeuft der Hochlauf ins Leere: Die
+    // Bridge nimmt ihre Register nicht an oder das Panel zeigt trotz korrekt gesendeter
+    // DSI-Daten nichts - beides ohne Fehlermeldung, weil aus Sicht des P4 alles geklappt
+    // hat. Das Ergebnis war ein Display, das mal ansprang und mal nicht.
+    //
+    // Der Werks-Testsketch wartet aus demselben Grund 2 Sekunden am Anfang von setup().
+    // Dass es mit geoeffnetem seriellen Monitor fast immer klappte, hatte dieselbe
+    // Ursache: Dessen USB-Anmeldung verzoegert den Start und ersetzte damit die Wartezeit.
+    vTaskDelay(pdMS_TO_TICKS(WS7_PANEL_WARMUP_MS));
+#endif
     jc_backlight_init();
 
 #if JC_PANEL_TYPE == WS_PANEL_7H
@@ -399,6 +452,16 @@ bool jc_board_bringup(void)
         .sda_io_num = BSP_I2C_SDA,
         .scl_io_num = BSP_I2C_SCL,
         .i2c_port = BSP_I2C_NUM,
+#if JC_PANEL_TYPE == WS_PANEL_7H
+        // Stoerimpulsfilter und interne Abschlusswiderstaende - beides setzt auch das
+        // Waveshare-Beispiel. Ohne den Filter brechen Bridge und Touch weg, sobald die
+        // DSI-Ausgabe laeuft: Deren schnelle Signale stoeren auf das lange Flachbandkabel
+        // ein, und ungefilterte Stoerspitzen bringen die I2C-Uebertragung aus dem Tritt.
+        // Der Audio-Baustein auf der Platine bleibt dabei erreichbar, weil er nicht am
+        // Displaykabel haengt - genau dieses Muster war im Start-Log zu sehen.
+        .glitch_ignore_cnt = 7,
+        .flags.enable_internal_pullup = true,
+#endif
     };
     i2c_new_master_bus(&i2c_bus_conf, &s_i2c_handle);
 
@@ -480,19 +543,34 @@ bool jc_board_bringup(void)
         return false;
     }
 
-    // Panel wecken (MADCTL / Sleep Out / Display On). Ein Reset gibt es hier nicht:
-    // ein reines DPI-Panel kennt keine reset-Funktion, esp_lcd_panel_reset() wuerde
-    // ins Leere greifen.
-    {
-        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
-        vTaskDelay(pdMS_TO_TICKS(120));
-        esp_lcd_panel_io_tx_param(io, 0x29, &zero, 1);   // Display On
-        vTaskDelay(pdMS_TO_TICKS(20));
-    }
+    ws7_panel_wake(io, "vor dem Start der Videoausgabe");
+
     BSP_STEP(esp_lcd_panel_init(disp_panel), "DPI-Videoausgabe starten");
+
+    // Zweiter Anlauf, jetzt bei laufender Videoausgabe: faengt den Fall ab, dass das
+    // Panel beim ersten Mal noch nicht aufnahmebereit war.
+    vTaskDelay(pdMS_TO_TICKS(WS7_PANEL_SETTLE_MS));
+    ws7_bridge_core_init("nach dem Start der Videoausgabe");
+    ws7_panel_wake(io, "nach dem Start der Videoausgabe");
+#if WS7_TEST_PATTERN
+    // Prueffarbbalken: Sie entstehen im DSI-Baustein selbst und benutzen weder den
+    // Bildspeicher noch LVGL. Erscheinen sie, arbeitet die Anzeigekette bis zum Panel und
+    // der Fehler liegt weiter oben. Bleibt es schwarz, liegt es an DSI, Zeitbasis oder
+    // Panel.
+    //
+    // Der Hochlauf endet hier bewusst: Wuerde LVGL danach starten, schriebe es sofort in
+    // den Bildspeicher und das Pruefbild waere wieder weg - der Test saehe dann genauso
+    // aus wie der Fehler, den er finden soll.
+    jc_backlight_set(100);          // Beleuchtung an, sonst ist nichts zu sehen
+    BSP_STEP(esp_lcd_dpi_panel_set_pattern(disp_panel, MIPI_DSI_PATTERN_BAR_VERTICAL),
+             "Prueffarbbalken");
+    esp_rom_printf("[Panel] Pruefbild steht - erwartet werden senkrechte Farbbalken.\n");
+    esp_rom_printf("[Panel] Hochlauf endet hier (WS7_TEST_PATTERN = 1, keine Oberflaeche).\n");
+    return false;                   // ohne LVGL: Anzeige bleibt beim Pruefbild
+#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();
@@ -638,7 +716,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

@@ -145,6 +145,22 @@
 // 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.
+// Anlaufzeit des Displaymoduls, bevor Bridge und Panel angesprochen werden. Ohne diese
+// Pause startet die Anzeige nur zufaellig - der Werks-Testsketch wartet aus demselben
+// Grund 2 Sekunden. Springt das Display beim Einschalten nicht zuverlaessig an, ist das
+// der erste Wert zum Erhoehen; laeuft es sicher, kann er vorsichtig gesenkt werden.
+#define WS7_PANEL_WARMUP_MS 2000
+
+// Pause zwischen dem Start der Videoausgabe und dem zweiten Anlauf der Weckbefehle.
+// Verpasst das Panel den ersten Anlauf, bleibt der Bildschirm dunkel, waehrend die
+// Beleuchtung brennt - sie haengt an der Bridge, nicht am Panel.
+#define WS7_PANEL_SETTLE_MS 200
+
+#define WS7_TEST_PATTERN 0
+
 #elif JC_PANEL_TYPE == JC_PANEL_70
 
 #define LCD_H_RES 1024