LCD Display Problem

[Max M. (max_52)]

Hallo Zusammen!
Ich habe bei einem Gerät (Lexicon MRC) das Display ausgetauscht und zwei 
unterschiedlichen Displays ausprobiert. Das grüne Display funktioniert 
einwandfrei. Beim blauen Display gibt es nach ein paar Sekunden Probleme 
siehe Fotos. Das heisst dass nach dem einschalten die Zeichen vorerst 
korrekt angezeigt werden, nach einigen Sekunden spielt die Anzeige 
jedoch verrückt. Komisch ist auch dass wenn ich einen Wert verändere 
wieder alles korrekt angezeigt wird. Nach ein paar Sekunden fängt das 
Problem jedoch wieder an.
Hat jemand einen Hinweis woran das liegen könnte?

Grünes Display = DEM 24252 SYH-LY/A
Blaues Display = W242B-NLW

Vielen Dank für Eure Hinweise

[Oliver S. (oliverso)]

Max M. schrieb:
> Hat jemand einen Hinweis woran das liegen könnte?

Das wird ein Timing-Problem sein. Das eine Display geht so noch gerade, 
das andere nicht.

Oliver

[Rainer W. (rawi)]

Max M. schrieb:
> Hat jemand einen Hinweis woran das liegen könnte?

Vielleicht liegt es an der Schaltung (Logikpegel, Versorgungsspannung, 
offene Pins).

[Teo D. (teoderix)]

Oliver S. schrieb:
> Max M. schrieb:
>> Hat jemand einen Hinweis woran das liegen könnte?
>
> Das wird ein Timing-Problem sein.

Sind das immer noch R/C Oszillatoren?!
Wärm das Display mal an, wenn's besser oder schlechter wird, is es 
definitiv ein Timing-Problem.
Die Wartezeiten auf die Befehlsabarbeitung sind zu kurz, nehm ich mal 
an.

[Sherlock 🕵🏽‍♂️ (rubbel-die-katz)]

Die Stromversorgung würde ich auch als erstes mit einem Oszilloskop 
prüfen. Danach die Qualität der Signale (Pegel und Flanken-Steilheit).

Bei den HD44780 kompatiblen Display habe ich die Erfahrung gemacht, daß 
viele erheblich schneller sind, als das Original. Viele im Netzt 
veröffentlichte Code-Beispiele halten sich nicht vollständig an das 
geforderte Timing, ohne daß es dem Autor aufgefallen ist.

Da kann es durchaus passieren, das ein bisher bewährter Programmcode an 
einem neuen (langsamen) Display plötzlich doch nicht mehr so stabil 
läuft, wie bisher.

Ergo: Timing ausmessen und mit dem richtigen Datenblatt vergleichen. 
Nicht nur auf einzelne Bytes achten, sondern auch die geforderten 
Wartezeiten nach Kommandos kontrollieren. Das teht am Besten mit einem 
Logic Analyzer, zur Not aus dem Quelltext heraus lesen.

[Max M. (max_52)]

Hallo Zusammen!
Vielen Dank für Eure Hinweise und Tipps!
Na dann werde ich mich mal an die Arbeit machen und als erstes 
Datenblätter studieren.
Nochmals Danke und Happy Weekend

[Rainer W. (rawi)]

Max M. schrieb:
> Beim blauen Display gibt es nach ein paar Sekunden Probleme
> siehe Fotos.

Was heißt das?
Macht das Display das von sich aus oder passieren die Probleme, während 
das Gerät mit ihm kommuniziert?

Die Datenblätter nützen dir nur wenig, solange du nicht misst, was in 
deinem Gerät passiert. Als erstes wäre es daher gut, zu gucken, was an 
Messtechnik zur Verfügung steht, um den Dingen auf den Grund zu gehen.

[Motopick (motopick)]

Rainer W. schrieb:

> ... um den Dingen auf den Grund zu gehen.

Und nachdem Datenblaetter studiert (*1) und das Timing des Geraets
vermessen wurde (*2), stellt man fest, dass man daran ohnehin nichts
aendern kann.

Also baut man wieder das Display ein, dass funktioniert.

Man haette sich 1. und 2. also sparen koennen.

[Rainer W. (rawi)]

Motopick schrieb:
> Also baut man wieder das Display ein, dass funktioniert.
>
> Man haette sich 1. und 2. also sparen koennen.

... und gelernt hätte man rein gar nichts.

[Max M. (max_52)]

Rainer W. schrieb:

> Was heißt das?
> Macht das Display das von sich aus oder passieren die Probleme, während
> das Gerät mit ihm kommuniziert?

Wie ich geschrieben habe, ich schalte das Gerät ein, Anzeige 
einwandfrei, nach ein paar Sekunden werden nach und nach die Zeichen 
verändert ohne dass ich was mache.

[Mi N. (msx)]

Oliver S. schrieb:
> Max M. schrieb:
>> Hat jemand einen Hinweis woran das liegen könnte?
>
> Das wird ein Timing-Problem sein. Das eine Display geht so noch gerade,
> das andere nicht.

Da das Schreiben klappt, wird es wohl nicht am Timing liegen. Der 
RAM-Inhalt 'löst' sich wohl auf - nach und nach, wie beschrieben.
Vielleicht einfach nur kaputt ;-)

[Malte _. (malte)]

Max M. schrieb:
> Wie ich geschrieben habe, ich schalte das Gerät ein, Anzeige
> einwandfrei, nach ein paar Sekunden werden nach und nach die Zeichen
> verändert ohne dass ich was mache.
Unter der Annahme dass das der Controller nicht ständig den selben 
Inhalt an das Display sendet (was mit einem Logikanalyzer der Oszi zu 
überprüfen wäre), müssten es demnach unpassende Logikpegel oder 
Störungen und weniger Timing sein. Schaltet der Controller eventuell bei 
Inaktivität die Ausgänge Hochohmig? Vielleicht hilft einen Pull-Down am 
Enable Pin hinzufügen?

[Crazy Harry (crazy_h)]

Max M. schrieb:
> DEM 24252 SYH-LY/A
Controller HD44780

> W242B-NLW
Controller HD44780 / ST7066 kompatibel

Wenn man das liest, ist Vorsicht geboten. Befehlskompatibel heißt nicht 
timingkompatibel. Deswegen haben andere schon geflucht.

[Harald K. (kirnbichler)]

Mi N. schrieb:
> Da das Schreiben klappt, wird es wohl nicht am Timing liegen.

Vielleicht doch; sobald der Displaycontroller auf Betriebstemperatur 
ist, kommt ihm irgendne Flanke zu früh.

Test: Displayrückseite vorsichtig erwärmen, dann Gerät einschalten.

Nächster Test: Displayrückseite mit Kältespray abkühlen, verschwindet 
der Effekt wieder?

[Motopick (motopick)]

Rainer W. schrieb:
> Motopick schrieb:
>> Also baut man wieder das Display ein, dass funktioniert.
>>
>> Man haette sich 1. und 2. also sparen koennen.
>
> ... und gelernt hätte man rein gar nichts.

Wie es scheint, ist der TO meiner Argumentation gefolgt. :)

So ein "korruptes" Display ist mir aber auch schon untergekommen.
Das war aber ein Grafisches in einem MP3-Player.
Mein Lernerfolg damals war, dass Flashspeicher bei zu niedriger
Betriebsspannung seinen Inhalt korrumpiert...
Sehr viel spannender verlief dann die Suche nach der Recoverysoftware.
Nach gefuehlten 2 Dutzend Fehlversuchen fand sich dann eine passende.
Ansonsten ein schoenes Stueck Hardware dessen Kern auf dem guten™
Motorolla 56000 basiert. Mit ein wenig Aufwand haette Mann auch
noch ein nettes Effektgeraet auf dem Stick laufen lassen koennen.
AD- und DA-Wandler waren ja auch schon da...

Eigenltich muessten die Hersteller von solchen Flashspeichern ihren
Produkten noch einen Spannungssupervisor beistellen oder am besten
in ihre Produkte integrieren, um solches "Fehlverhalten" sicher
auszuschliessen. Unter anderem sind z.B. auch Notebooks davon
betroffen.

Frohen Advent!

[Rainer W. (rawi)]

Harald K. schrieb:
> Vielleicht doch; sobald der Displaycontroller auf Betriebstemperatur
> ist, kommt ihm irgendne Flanke zu früh.

Flanken kommen nur, wenn der µC mit dem Display kommuniziert. Die Frage 
von gestern ist immer noch offen:

Rainer W. schrieb:
> Macht das Display das von sich aus oder passieren die Probleme, während
> das Gerät mit ihm kommuniziert?

[Harald K. (kirnbichler)]

Daß gleich zwei neue Displays das gleiche bizarre Fehlerverhalten 
zeigen, legt nahe, daß das kein Fehler ist, den das Display alleine, 
ohne Ansteuerung hinbekommt. Also halte ich Deinen Vorschlag, das 
Display "solo" zu untersuchen, für einen nachrangigen Nebenschauplatz.

Ich halte es für erheblich wahrscheinlicher, daß hier ein Timing-Problem 
vorliegt, und der Datenbus am Display nicht zu dem Zeitpunkt stabil ist, 
zu dem das Display die anliegenden Daten übernehmen will (das sollte 
eine gewisse Zeit nach der fallenden Flanke von E geschehen).

Im Datenblatt des HD44780 
(https://www.sparkfun.com/datasheets/LCD/HD44780.pdf) ist auf Seite 58 
ein Timingdiagramm abgebildet, und die kritischen Zeiten beim 
Schreibzugriff sind
- tcycE (Zykluszeit eines kompletten Zugriffs)
- tAS (Signale RS und R/!W stabil vor steigender Flanke von E)
- tEr (Anstiegszeit steigende Flanke von E)
- tDSW (Daten stabil auf Datenbus vor fallender Flanke von E)
- tH (Daten stabil auf Datenbus nach fallender Flange von E)

Die typischen Werte dazu listet das Datenblatt auf Seite 52 auf:

tcycE min 500 ns (d.h. maximal 2 MHz Takt auf E)
tAS min 40 ns
tEr max 20 ns
tDSW min 80 ns
tH min 10 ns

Das sind die Werte des Originals, im vom Original vorgesehenen 
Betriebsspannungsbereich.

Da natürlich sehr viele Displays nicht mehr mit dem Original, sondern 
nur "kompatiblen" Nachbauten betrieben werden, ist das nicht in der Erde 
festgemeißelt; idealerweise sollte man sich die betreffenden Werte im 
Datenblatt des realen Controllers ansehen, was voraussetzt, daß man 
überhaupt herausfindet, welcher das ist (auf etlichen Displays ist nur 
der beliebte schwarze Klecks drauf).

Weiterhin kann es Abweichungen durch geänderte Signalpegel geben. Die 
meisten neuzeitlichen Klone des 44780 funktionieren auch problemlos mit 
3.3 V Versorgunsspannung, wenn man die Kontrastspannung entsprechend 
anpasst. Sie lassen sich aber auch im 5 V-Betrieb mit Spannungspegeln 
eines mit 3.3 V betriebenen µC ansteuern, nur kann es dann zu 
Verschleifungen kommen, weil eben High-Pegel erst später eine für den 
44780 ausreichend hohe Spannung bekommen.

Mir scheint hier der Einsatz eines Oszilloskopes angebracht zu sein, um 
zu prüfen, wie das vorgegebene Gerät überhaupt das Display ansteuert. 
Versorgungsspannung, Signalpegel und Timing.

[Sherlock 🕵🏽‍♂️ (rubbel-die-katz)]

Harald K. schrieb:
> Die
> meisten neuzeitlichen Klone des 44780 funktionieren auch problemlos mit
> 3.3 V Versorgunsspannung, wenn man die Kontrastspannung entsprechend
> anpasst

Das war schon beim Original so. Selbst mit 5V Versorgung reichen Signale 
mit 3,3V.

Harald K. schrieb:
> Mir scheint hier der Einsatz eines Oszilloskopes angebracht zu sein, um
> zu prüfen, wie das vorgegebene Gerät überhaupt das Display ansteuert.
> Versorgungsspannung, Signalpegel und Timing.

Ja

[Mi N. (msx)]

Harald K. schrieb:
> Daß gleich zwei neue Displays das gleiche bizarre Fehlerverhalten
> zeigen,

Lies noch mal nach: eins funktioniert (grün) und eins nicht (blau).
Ein Display kann auch mal defekt sein. Hau weg den Schrott! ;-)

[Harald K. (kirnbichler)]

Mi N. schrieb:
> Lies noch mal nach: eins funktioniert (grün) und eins nicht (blau).

Gut, OK, ich hatte mich daran falsch erinnert.

Mi N. schrieb:
> Ein Display kann auch mal defekt sein.

Sicher kann es das. Aber hast Du schon mal ein Display mit diesem 
bizarren Fehler gesehen?

Gut, wir wissen auch nicht, ob das Display Neuware ist, oder ob der 
Threadstarter es irgendwo aus dem Recycling hat.

Hinweise zur Untersuchung haben wir jetzt aber genügend gegeben.

[Mi N. (msx)]

Harald K. schrieb:
> Sicher kann es das. Aber hast Du schon mal ein Display mit diesem
> bizarren Fehler gesehen?

Im Laufe der Zeit sieht man sehr viel und glaubt an garnichts mehr ;-)
Selbst, wenn das Display nagelneu ist, kann ein visueller Test klaglos 
durchlaufen werden. Niemand wird sich 1 h davor setzen, um zusehen, ob 
die Anzeige statisch stabil bleibt.
Bei Problemen mit dem Timing klappt meist die Initialisierung schon 
nicht.

Meinerseits würde ich das betreffende Display an eine eigene Schaltung 
anschließen. Wenn der Fehler bleibt, ist die Ursache klar.
Vielleicht hat der TO ein Arduino- oder RP2040-Board. da gibt es doch 
genug direkt aufspielbare Beispielprogramme.

[Max M. (max_52)]

Hallo Zusammen!
Das blaue Display ist neu, habe zwei davon, eines REV.0, das andere 
REV.E,
beide zeigen das selbe Fehlerbild.
Das Gerät hat Schieberegler um Werte einzustellen. Bediene ich einen 
Regler, verschwindet das Fehlerbild sofort und die Anzeige sieht normal 
aus. Nach 2-3 Sekunden fängt die Anzeige wieder an mit dem Fehlerbild, 
welches sich nach und nach aufbaut. Also zuerst ein Zeichen, dann folgen 
weitere mit komischen Anzeigen.
Kann leider keine Messung mit dem Oszi machen da ich es verkauft habe.

[H. H. (hhinz)]

Max M. schrieb:
> Kann leider keine Messung mit dem Oszi machen

Logikanalysator wäre eh besser.

[Motopick (motopick)]

Mi N. schrieb:
> Harald K. schrieb:
>> Daß gleich zwei neue Displays das gleiche bizarre Fehlerverhalten
>> zeigen,
>
> Lies noch mal nach: eins funktioniert (grün) und eins nicht (blau).
> Ein Display kann auch mal defekt sein. Hau weg den Schrott! ;-)

Das ist wohl eher Altersdemenz (beim Display :).

[Teo D. (teoderix)]

Max M. schrieb:
> Das blaue Display ist neu, habe zwei davon, eines REV.0, das andere
> REV.E,
> beide zeigen das selbe Fehlerbild.

Aha, die Neuen sinds... Haben da evtl. die Eingänge die Segel gehisst?
Bzw.fehlen da Pull-Down Widerstände.

[Hugo H. (hugo_hu)]

Fällt Dir da irgendetwas auf? (-> Bilder)

[Teo D. (teoderix)]

Hugo H. schrieb:
> Fällt Dir da irgendetwas auf? (-> Bilder)

Diese Befehle nutzt doch keiner und schon garnicht wirr mal so 
zwischendurch!

[Hugo H. (hugo_hu)]

Teo D. schrieb:
> Diese Befehle nutzt doch keiner und schon garnicht wirr mal so
> zwischendurch!

Gibt es Deine Glaskugel irgendwo zu kaufen?

[Rainer W. (rawi)]

Hugo H. schrieb:
> Fällt Dir da irgendetwas auf? (-> Bilder)

Execution Time (f_Osc = 270 kHz) vs. Execution Time (max.)
Fällt dir irgendetwas auf?

Ohne die Oszillatorfrequenz bzw. deren Toleranzbereich zu kennen, ist 
das ein Vergleich von Apfeln mit Birnen.

[Hugo H. (hugo_hu)]

Rainer W. schrieb:
> Ohne die Oszillatorfrequenz bzw. deren Toleranzbereich zu kennen, ist
> das ein Vergleich von Apfeln mit Birnen.

Die Oszillatorfrequenz (alt) ist bekannt (steht im Datenblatt und ist 
dort angegeben, da der Controller - auch im Datenblatt referenziert - 
mit mehreren Frequenzen betrieben werden kann).
Daher sind auch die Ausführungszeiten (alt) bekannt.

Die Ausführungszeiten (neu) werden für die maximal zulässige 
"Betriebsfrequenz" angegeben, was ich für sinnvoll halte. Damit kann 
beides verglichen werden und es ist schon eine deutliche Diskrepanz 
bemerkbar.

Niemand von uns (vermute ich mal) kennt die genaue zeitliche und 
programmtechnische Ansteuerung des Displays. Kann man mit einem billigen 
LA recht gut herausfinden, wenn man das will.

Programmtechnisch ist es nicht zuletzt deshalb interessant, weil nicht 
jeder / jede Bibliothek das Busy-Flag abfragt, was im Fall des "neuen" 
Displays fatal sein kann. Von uns weiß vermutlich auch niemand, in 
welchem Modus das Display angesteuert wird.

Zitat aus dem Datenblatt (neu):
HINWEIS Die in der Tabelle angegebenen Ausführungszeiten gelten nur bei 
Abfrage des Busy Flags; d.h. vor jedem Schreib- und Lesezugriff muß das 
Busy Flag BF auf 0 abgefragt werden. Wird das Busy Flag nicht abgefragt, 
so sind die Ausführungszeiten zum Teil wesentlich länger als angegeben. 
Im 4-Bit Mode ist die Busy-Abfrage vor jedem Bytezugriff notwendig.

Datenblätter liest nicht jeder - ich finde es durchaus sinnvoll mal 
reinzuschauen :-).

[Peter D. (peda)]

Max M. schrieb:
> Komisch ist auch dass wenn ich einen Wert verändere
> wieder alles korrekt angezeigt wird. Nach ein paar Sekunden fängt das
> Problem jedoch wieder an.

Ja, sieht nach Wackelkontakt (Kabelbruch, kalte Lötstelle) aus.
Die neuen Daten werden kapazitiv übertragen und dann floaten die Pins 
wieder.

Am Timing liegt es definitiv nicht.

[Ada J. Quiroz (inschnier)]

Das Problem hatte ich auch beim Tauschen eines alten Displays gegen ein 
neues. Die Timings waren nicht die gleichen und die alte Firmware aus 
den 90ern war halt auf ein anderes Timing angepasst.

Die Lösung war, dass auf der Rückseite vom neuen LCD ein Widerstand ist, 
welcher die Taktfrequenz des LCDs bestimmt. Eine Änderung von diesem 
Wert hat den Fehler behoben. Ich musste etwas ausprobieren, bis ich den 
korrekten Wert gefunden habe.

Einfach in 10ner Schritten rauf und runtergehen, ca 2 Stunden Arbeit.

[Teo D. (teoderix)]

Max M. schrieb:
> Das blaue Display ist neu, habe zwei davon, eines REV.0, das andere
> REV.E,
> beide zeigen das selbe Fehlerbild.

Max M. schrieb:
> W242B-NLW

Im DB steht bei denen als troubleshooting "Pull-Up Widerstand direkt am 
LCD-Modu". Die internen Pull-Up Transistoren, könnten bei diesen 
Modellen etwas zu mau sein!?

[Sherlock 🕵🏽‍♂️ (rubbel-die-katz)]

Hugo H. schrieb:
> Im 4-Bit Mode ist die Busy-Abfrage vor jedem Bytezugriff notwendig.

Vermutlich hast du den Satz anders gemeint, als er wirkt. Der 4-Bit 
Modus funktioniert auch ohne Busy-Abfrage (z.B. mit passenden Delays) 
tadellos.

[Hugo H. (hugo_hu)]

Sherlock 🕵🏽‍♂️ schrieb:
> Hugo H. schrieb:
>> Im 4-Bit Mode ist die Busy-Abfrage vor jedem Bytezugriff notwendig.

Das ist ein Zitat aus dem Datenblatt für das "neue / blaue" Display 
W242B-NLW - deswegen steht auch "Zitat" drüber :-).

https://www.mouser.de/datasheet/2/127/2_24-1915198.pdf

[Sherlock 🕵🏽‍♂️ (rubbel-die-katz)]

Hugo H. schrieb:
> Das ist ein Zitat aus dem Datenblatt

Danke.

HINWEIS
Die in der Tabelle angegebenen
Ausführungszeiten gelten nur bei
Abfrage des Busy Flags; d.h. vor
jedem Schreib- und Lesezugriff
muß das Busy Flag BF auf 0
abgefragt werden. Wird das Busy
Flag nicht abgefragt, so sind die
Ausführungszeiten zum Teil
wesentlich länger als angegeben.
Im 4-Bit Mode ist die Busy-Abfrage
vor jedem Bytezugriff notwendig.

Und "wesentlich länger" ist nicht weiter spezifiziert, nicht mal 
ungefähr.

Ich bin negativ beeindruckt. Denn das ist beim originalen HD44780 
definitiv nicht so. Dann ist das ja der wahrscheinlichste Show-Stopper 
gegen einen einfachen Hardwaretausch.

[Teo D. (teoderix)]

Hugo H. schrieb:
> Sherlock 🕵🏽‍♂️ schrieb:
>> Hugo H. schrieb:
>>> Im 4-Bit Mode ist die Busy-Abfrage vor jedem Bytezugriff notwendig.
>
> Das ist ein Zitat aus dem Datenblatt für das "neue / blaue" Display
> W242B-NLW - deswegen steht auch "Zitat" drüber :-).

Hat ich so mal (versehentlich) für HD44780 Kompatible programmiert, also 
bei jedem 4Bit Zugriff... Tut natürlich nicht, abfragen erst nach dem 
2.Nibble!

[Mi N. (msx)]

Hugo H. schrieb:
> Wird das Busy Flag nicht abgefragt,
> so sind die Ausführungszeiten zum Teil wesentlich länger als angegeben.

Lass mich raten: wesentlich = 10 µs
Noch einmal: Wenn das Timing nicht stimmt, bekommt man ersteinmal 
garkeine sinnvolle Anzeige zustande.
Und auch dies noch einmal: Ansteuerung mit einem anderen Gerät/Schaltung 
testen.

[Peter D. (peda)]

Es kann auch ein Softwarefehler vorliegen, der µC schaltet die 
LCD-Leitungen zwischen den Ausgaben wieder auf floatend.
Das eine LCD könnte einen Pulldown am E-Pin haben, das andere nicht.
Mit einem DMM gegen VCC kann man messen, ob der E-Pin floatet oder auf 
low gezogen wird.
Man könnte dann einen Pulldown (10k) nachrüsten, an die SW wird man wohl 
nicht rankommen.

[Frank E. (Firma: Q3) (qualidat)]

Ich würde das (vermutlich) defekte LCD mal ausserhalb des Gerätes 
betreiben, ist ja z.B. mit einem Arduino kein großes Problem. Dann 
könnte man zumindest erstmal eingrenzen, ob es an der Art der 
Ansteuerung im "Lexicon MRC" oder tatsächlich am LCD selbst liegt ...