Compare commits

..
Author SHA1 Message Date
raw-designsandClaude Opus 5 80b6eb810f 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
2026-09-01 17:24:25 +02:00
thomas 6a9048411e Merge pull request 'fix(P4): I2C-Störimpulsfilter - Ursache des schwarzen Bildes (1.6.16)' (#44) from fix/i2c-stoerimpulsfilter into main 2026-09-01 17:06:15 +02:00
raw-designsandClaude Opus 5 ecb9836510 fix(P4): I2C-Störimpulsfilter - Ursache des schwarzen Bildes (1.6.16)
Der I2C-Scan vor und nach dem Panel-Start war entscheidend:

  vor:   0x14 (Touch)  0x18 (Audio)  0x45 (Bridge)
  nach:  0x18

Es fallen genau die beiden Bausteine weg, die am Displaykabel hängen; der
Audio-Baustein auf der Platine bleibt erreichbar, der Bus arbeitet also.
Sobald die DSI-Ausgabe läuft, stören deren Signale auf das Flachbandkabel
ein. Die Bridge liess sich danach nicht mehr ansprechen
(ESP_ERR_INVALID_STATE), das Panel blieb dunkel.

i2c_master_bus_config_t bekommt für WS_PANEL_7H jetzt glitch_ignore_cnt = 7
und enable_internal_pullup - beides setzt auch das Waveshare-Beispiel. In
unserem Bringup fehlte es, weil die Bus-Einrichtung von den JC-Panels
übernommen wurde, die kein Flachbandkabel dieser Länge haben.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018QoLDQeUh1dCQz7yYZVb4Y
2026-09-01 17:04:51 +02:00
thomas c4cb6eb90a Merge pull request 'diag(P4): Schwarzes Bild eingrenzen - Prüfbild und lückenlose Meldungen (1.6.15)' (#43) from diag/schwarzes-bild-eingrenzen into main 2026-09-01 16:52:28 +02:00
raw-designsandClaude Opus 5 c58b901f26 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
2026-09-01 16:51:04 +02:00
thomas d83619904f Merge pull request 'fix(P4): Touch erst nach Panel-Freigabe initialisieren (1.6.14)' (#42) from fix/touch-nach-panelfreigabe into main 2026-09-01 16:31:55 +02:00
raw-designsandClaude Opus 5 50540179c7 fix(P4): Touch erst nach Panel-Freigabe initialisieren (1.6.14)
Der GT9271 meldete "i2c transaction failed" auch beim Kaltstart, während
alle Panel-Schritte fehlerfrei durchliefen und die Bus-Freitaktung aus 1.6.13
den Bus als frei meldete.

Ursache ist die Reihenfolge: Im funktionierenden Werks-Testsketch steht
initTouch() hinter enableBacklight(). Der GT9271 hängt an derselben
Versorgung wie das Panel und antwortet erst, wenn die Bridge über 0xAD
freigegeben ist. Beim Übertragen in die Firmware war das verloren gegangen -
jc_backlight_set() lief erst nach jc_board_bringup().

- Für WS_PANEL_7H wird die Beleuchtung jetzt innerhalb des Bringups vor der
  Touch-Initialisierung eingeschaltet, mit WS7_TOUCH_POWER_MS Pause.
- Neue Diagnose ws7_i2c_scan() listet die antwortenden I2C-Adressen vor und
  nach dem Panel-Start.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018QoLDQeUh1dCQz7yYZVb4Y
2026-09-01 16:30:31 +02:00
thomas 9bbd7d72aa Merge pull request 'fix(P4): Hängenden I2C-Bus freitakten - Ursache des schwarzen Bildes (1.6.13)' (#41) from fix/i2c-bus-freitakten into main 2026-09-01 16:17:42 +02:00
3 changed files with 120 additions and 3 deletions
+51
View File
@@ -1,3 +1,54 @@
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
+59 -3
View File
@@ -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
@@ -385,10 +399,21 @@ 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);
#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 +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();
@@ -567,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.
@@ -613,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;
}
+10
View File
@@ -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