diag(P4): Prüfbild hält an, statt von LVGL überschrieben zu werden (1.6.17)

Der Störimpulsfilter aus 1.6.16 wirkt - nach dem Panel-Start melden sich
wieder alle drei I2C-Bausteine, keine Bridge- oder Touch-Fehler mehr.

Das Prüfbild aus 1.6.15 war als Test jedoch untauglich: gesetzt bei
esp_lcd_dpi_panel_set_pattern(), aber unmittelbar danach lief
lvgl_port_init() und schrieb in den Framebuffer, womit das Muster wieder
verschwand. Der Test sah damit genauso aus wie der Fehler, den er finden
soll.

Mit WS7_TEST_PATTERN = 1 endet jc_board_bringup() jetzt direkt nach dem
Muster: Backlight an, Rückgabe false, kein LVGL.

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

P4_Display_Firmware/Changelog.txt

@@ -1,15 +1,81 @@
-Version 1.6.11:
-- Fehlerbehebung: Nach einem Reset des P4 blieb das Bild schwarz, während die
-  Hintergrundbeleuchtung brannte; erst ein erneutes Flashen half. Die Bridge des
-  Waveshare-Panels hat keine Reset-Leitung und hängt an Dauerstrom - ein Reset des P4
-  setzt sie also nicht zurück, ihre Register standen noch auf den Werten der vorigen
-  Sitzung. Der P4 baut seine DSI-Strecke aber komplett neu auf, und ein frischer DSI-Start
-  auf einer bereits laufenden Bridge liefert kein Bild. Beim Flashen wird die Versorgung
-  getrennt, deshalb war der Fehler dort nicht zu sehen.
-- Der Start schaltet die Bridge jetzt zuerst definiert ab (Beleuchtung, dann Ausgabe,
-  dann Grundregister), wartet WS7_BRIDGE_RESET_MS und fährt sie erst danach hoch. Der
-  Wert steht in pins_config.h (Vorgabe 120 ms) und ist die erste Stellschraube, falls
-  nach einem Reset doch einmal ein schwarzes Bild auftaucht.
+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
+  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
+  Bitausgabe stehen und haelt die Datenleitung dauerhaft auf Masse. Damit schlaegt jede
+  weitere Uebertragung fehl. Bridge und Touch-Controller haengen an Dauerstrom, weshalb
+  dieser Zustand jeden Reset und sogar das Flashen ueberlebt - nur echtes Stromabziehen
+  loest ihn. Die Folge: Die Bridge wird nie initialisiert, das Bild bleibt schwarz, und
+  weil sie ihre Register behaelt, brennt die Hintergrundbeleuchtung weiter.
+- Vor dem Anlegen des I2C-Busses wird die Taktleitung jetzt von Hand getaktet, bis der
+  Baustein die Datenleitung freigibt, danach folgt eine Stopp-Bedingung. Das ist der in
+  der I2C-Spezifikation vorgesehene Weg und laeuft bei freiem Bus wirkungslos durch.
+- Fehlerbehebung: Schreibzugriffe auf die Bridge liefen stillschweigend ins Leere. Genau
+  deshalb war der Fehler so schwer zu finden - das Bild blieb ohne jeden Hinweis schwarz.
+  Sie melden Fehler jetzt im Klartext.
+- Fehlerbehebung: In pins_config.h stand seit 1.6.10 "#elsealle" statt "#else". Der
+  Tippfehler traf nur den Zweig des 4,3-Zoll-Panels, das damit nicht mehr uebersetzbar war.
+  Beide Panel-Varianten sind jetzt wieder gegengebaut.
+
+Version 1.6.12:
+- Die Abschaltfolge für die Bridge aus 1.6.11 ist zurückgenommen. Sie hat den Fehler nicht
+  behoben, sondern verschlimmert: Nach dem Nullsetzen von C0/C2/AC kam das Panel auch
+  direkt nach dem Flashen nicht mehr hoch, die normale Einschaltfolge holt es aus diesem
+  Zustand nicht zurück. Der Start entspricht damit wieder 1.6.10.
+- Stattdessen zwei Diagnosen, um die Ursache des schwarzen Bildes nach einem Reset
+  einzugrenzen: Der Startgrund wird beim Hochlauf ausgegeben (1 = Kaltstart, alles andere
+  Warmstart), und das Anfordern der Stromversorgung für die MIPI-Strecke wird jetzt auf
+  Fehler geprüft - bislang lief dieser Schritt als einziger ungeprüft durch.
 
 Version 1.6.10:
 - WS7_PARTIAL_REFRESH ist jetzt auch im Auslieferungsstand 1. Am Gerät geprüft: kein

P4_Display_Firmware/README.md

@@ -67,11 +67,6 @@ Das Panel hängt hinter einer Waveshare-Bridge und braucht **keinen** Hersteller
 - Reihenfolge: Bridge-Grundinitialisierung (`C0`/`C2`/`AC`) → DSI → DCS `MADCTL`/`Sleep Out`/
   `Display On` → DPI-Start → **erst dann** Hintergrundbeleuchtung. Wird das Licht früher
   eingeschaltet, blitzt beim Start Bildrauschen auf.
-- **Nach einem Reset:** Die Bridge hat keine Reset-Leitung und hängt an Dauerstrom — ein
-  Reset des P4 setzt sie **nicht** zurück. Der Bringup schaltet sie deshalb zuerst
-  definiert ab, wartet `WS7_BRIDGE_RESET_MS` und fährt sie dann neu hoch. Ohne das trifft
-  ein frischer DSI-Start auf eine noch laufende Bridge: Bild schwarz, Beleuchtung an.
-  Nach dem Flashen fällt das nicht auf, weil dabei die Versorgung getrennt wird.
 - **Einbaulage:** `WS7_ROTATE_180` in [`pins_config.h`](pins_config.h) dreht Bild **und**
   Touch um 180°, falls das Panel auf dem Kopf montiert wird. Vorgabe ist **0** — in der
   jetzigen Einbaulage steht das Bild richtig herum. Die Drehung macht der

P4_Display_Firmware/board_bringup.c

@@ -30,6 +30,7 @@
 #include "esp_heap_caps.h"
 #include "esp_rom_sys.h"
 #include "esp_timer.h"
+#include "esp_system.h"
 #include "esp_ldo_regulator.h"
 #include "esp_lcd_panel_io.h"
 #include "esp_lcd_panel_ops.h"
@@ -70,6 +71,82 @@
 
 static i2c_master_bus_handle_t s_i2c_handle = NULL;
 
+#if JC_PANEL_TYPE == WS_PANEL_7H
+// ------------------------------------------------------------------------------------
+//  Haengenden I2C-Bus befreien
+//
+//  Trifft ein Reset des P4 mitten in eine laufende I2C-Uebertragung, bleibt der
+//  angesprochene Baustein in seiner Bitausgabe stehen und haelt die Datenleitung dauerhaft
+//  auf Masse. Der Bus ist damit tot: Jede weitere Uebertragung schlaegt fehl. Da Bridge und
+//  Touch-Controller an Dauerstrom haengen, ueberlebt dieser Zustand jeden Reset und sogar
+//  das Flashen - nur echtes Stromabziehen loest ihn.
+//
+//  Folge: Die Bridge wird nie initialisiert, das Bild bleibt schwarz, und weil sie ihre
+//  Register behaelt, brennt die Hintergrundbeleuchtung weiter. Genau dieses Bild.
+//
+//  Abhilfe ist der uebliche Weg aus der I2C-Spezifikation: Vor dem Anlegen des Busses die
+//  Taktleitung von Hand takten, bis der Baustein sein letztes Bit ausgegeben hat und die
+//  Datenleitung wieder loslaesst, danach eine Stopp-Bedingung erzeugen.
+static void ws7_i2c_bus_recover(void)
+{
+    gpio_config_t io = {
+        .pin_bit_mask = BIT64(BSP_I2C_SDA) | BIT64(BSP_I2C_SCL),
+        .mode = GPIO_MODE_INPUT_OUTPUT_OD,     // offener Kollektor, Zustand lesbar
+        .pull_up_en = GPIO_PULLUP_ENABLE,
+        .pull_down_en = GPIO_PULLDOWN_DISABLE,
+        .intr_type = GPIO_INTR_DISABLE,
+    };
+    gpio_config(&io);
+    gpio_set_level(BSP_I2C_SDA, 1);
+    gpio_set_level(BSP_I2C_SCL, 1);
+    esp_rom_delay_us(10);
+
+    if (gpio_get_level(BSP_I2C_SDA) != 0) {
+        return;                                 // Bus frei - nichts zu tun
+    }
+
+    esp_rom_printf("[Panel] I2C-Bus haengt - wird freigetaktet\n");
+
+    // Bis zu neun Takte: so viele braucht ein Baustein hoechstens, um ein angefangenes
+    // Byte samt Bestaetigungsbit zu Ende zu schieben.
+    for (int i = 0; i < 9 && gpio_get_level(BSP_I2C_SDA) == 0; i++) {
+        gpio_set_level(BSP_I2C_SCL, 0);
+        esp_rom_delay_us(5);
+        gpio_set_level(BSP_I2C_SCL, 1);
+        esp_rom_delay_us(5);
+    }
+
+    // Stopp-Bedingung: Datenleitung geht bei hoher Taktleitung von Masse auf High.
+    gpio_set_level(BSP_I2C_SDA, 0);
+    esp_rom_delay_us(5);
+    gpio_set_level(BSP_I2C_SCL, 1);
+    esp_rom_delay_us(5);
+    gpio_set_level(BSP_I2C_SDA, 1);
+    esp_rom_delay_us(10);
+
+    esp_rom_printf("[Panel] I2C-Bus nach Freitakten: %s\n",
+                   gpio_get_level(BSP_I2C_SDA) ? "frei" : "weiterhin belegt");
+
+    // Pins wieder freigeben, damit der I2C-Treiber sie uebernehmen kann.
+    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
 // abgeschaltetem Core-Debug-Level und ohne Heap, also genau dann, wenn es darauf ankommt.
 #define BSP_STEP(call, what)                                                             \
@@ -107,19 +184,17 @@ static void ws7_bridge_write(uint8_t reg, uint8_t value)
 {
     if (s_bridge_handle == NULL) return;
     uint8_t buf[2] = { reg, value };
-    i2c_master_transmit(s_bridge_handle, buf, sizeof(buf), 100);
+    esp_err_t err = i2c_master_transmit(s_bridge_handle, buf, sizeof(buf), 100);
+    if (err != ESP_OK) {
+        // Frueher lief das stillschweigend ins Leere. Schlaegt es fehl, wird die Bridge
+        // nie initialisiert und das Bild bleibt schwarz - ohne jeden Hinweis darauf.
+        esp_rom_printf("[Panel] Bridge-Register 0x%02X liess sich nicht schreiben: %s\n",
+                       reg, esp_err_to_name(err));
+    }
 }
 
-// Bridge in einen definierten Grundzustand bringen und neu initialisieren.
-//
-// WICHTIG - der Grund fuer das Abschalten am Anfang: Die Bridge hat keine Reset-Leitung
-// und haengt an Dauerstrom. Ein Reset des P4 setzt sie also NICHT zurueck; ihre Register
-// stehen noch so, wie die vorige Sitzung sie hinterlassen hat. Der P4 baut seine
-// DSI-Strecke aber komplett neu auf. Trifft ein frischer DSI-Start auf eine bereits
-// laufende Bridge, bleibt das Bild schwarz, waehrend die Hintergrundbeleuchtung brennt.
-// Nach dem Flashen faellt das nicht auf, weil dabei die Versorgung getrennt wird.
-//
-// Deshalb erst ausschalten (Beleuchtung, dann Bridge), kurz warten, dann normal hochfahren.
+// Bridge am I2C-Bus anmelden und Grundinitialisierung schreiben. Muss VOR dem
+// DSI-Bringup laufen; die Hintergrundbeleuchtung bleibt dabei noch aus.
 static void ws7_bridge_pre_init(void)
 {
     i2c_device_config_t dev_cfg = {
@@ -131,22 +206,9 @@ static void ws7_bridge_pre_init(void)
         s_bridge_handle = NULL;
         return;
     }
-
-    // --- definierter Aus-Zustand (umgekehrte Reihenfolge zum Einschalten) ---
-    ws7_bridge_write(0xAB, 0xFF);   // Helligkeit 0
-    ws7_bridge_write(0xAA, 0x01);   // uebernehmen
-    ws7_bridge_write(0xAD, 0x00);   // Bridge-Ausgabe aus
-    vTaskDelay(pdMS_TO_TICKS(20));
-    ws7_bridge_write(0xAC, 0x00);
-    ws7_bridge_write(0xC2, 0x00);
-    ws7_bridge_write(0xC0, 0x00);
-    vTaskDelay(pdMS_TO_TICKS(WS7_BRIDGE_RESET_MS));
-
-    // --- Grundinitialisierung wie im Linux-Treiber ---
     ws7_bridge_write(0xC0, 0x01);
     ws7_bridge_write(0xC2, 0x01);
     ws7_bridge_write(0xAC, 0x01);
-    vTaskDelay(pdMS_TO_TICKS(20));
 }
 
 void jc_backlight_init(void)
@@ -328,25 +390,45 @@ bool jc_board_bringup(void)
 {
     jc_backlight_init();
 
+#if JC_PANEL_TYPE == WS_PANEL_7H
+    ws7_i2c_bus_recover();          // haengenden Bus vom letzten Reset befreien
+#endif
+
     i2c_master_bus_config_t i2c_bus_conf = {
         .clk_source = I2C_CLK_SRC_DEFAULT,
         .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);
 
 #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
 
+    // Reset-Grund mitschreiben: 1 = Kaltstart (Strom weg), alles andere ist ein Warmstart.
+    // Nur beim Warmstart behalten die Bausteine ihren alten Zustand - genau dann traten
+    // die schwarzen Bilder auf.
+    esp_rom_printf("[Panel] Startgrund: %d (1 = Kaltstart)\n", (int)esp_reset_reason());
+
     static esp_ldo_channel_handle_t phy_pwr_chan = NULL;
     esp_ldo_channel_config_t ldo_cfg = {
         .chan_id = BSP_MIPI_DSI_PHY_PWR_LDO_CHAN,
         .voltage_mv = BSP_MIPI_DSI_PHY_PWR_LDO_VOLTAGE_MV,
     };
-    esp_ldo_acquire_channel(&ldo_cfg, &phy_pwr_chan);
+    BSP_STEP(esp_ldo_acquire_channel(&ldo_cfg, &phy_pwr_chan), "Stromversorgung MIPI-D-PHY");
 
     esp_lcd_dsi_bus_handle_t mipi_dsi_bus;
     esp_lcd_panel_io_handle_t io = NULL;
@@ -414,13 +496,32 @@ 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 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();
@@ -510,6 +611,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.
@@ -556,7 +667,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/config.h

@@ -126,7 +126,7 @@
 // -------------------------------------------------------------------------------------
 //  Firmware
 // -------------------------------------------------------------------------------------
-#define DISPLAY_FW_VERSION       "1.6.11"   // Firmware-Stand der P4-Display-Steuerung (Info-Seite)
+#define DISPLAY_FW_VERSION       "1.6.10"   // Firmware-Stand der P4-Display-Steuerung (Info-Seite)
 
 // -------------------------------------------------------------------------------------
 //  Protokoll

P4_Display_Firmware/pins_config.h

@@ -114,12 +114,6 @@
 // nicht bekannt; die 180-Grad-Drehung macht deshalb der PPA (WS7_ROTATE_180).
 #define WS7_MADCTL           0x00
 
-// So lange bleibt die Bridge beim Start stromlos geschaltet, bevor sie neu
-// initialisiert wird. Sie hat keine Reset-Leitung und ueberlebt einen Reset des P4;
-// ohne diese Pause trifft ein frischer DSI-Start auf eine noch laufende Bridge und das
-// Bild bleibt schwarz. Bei schwarzem Bild nach Reset zuerst diesen Wert erhoehen.
-#define WS7_BRIDGE_RESET_MS  120
-
 // Der GT9271 meldet im Hochformat: Roh-X 0..720, Roh-Y 0..1280. Fuer das Querformat
 // werden die Achsen getauscht. Die Spiegelung geschieht VOR dem Tausch, also noch auf den
 // Rohwerten: Roh-X wird zur Bildschirmhoehe, Roh-Y zur Bildschirmbreite.
@@ -146,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
@@ -154,7 +158,7 @@
 #define LCD_RST 27
 #define LCD_LED 23
 
-#elsealle
+#else
 
 #define LCD_H_RES 480
 #define LCD_V_RES 800