Forum: Mikrocontroller und Digitale Elektronik Defektes Grafikdisplay W320-8k3


von Stefan T. (stefan90)


Angehängte Dateien:

Lesenswert?

Hallo,

ich habe von der Firma Electronic Assembly das Display W320-8K3 
http://www.lcd-module.de/deu/grafik/grafik.htm, Datenblatt 
http://www.lcd-module.de/deu/pdf/grafik/w320-8k3.pdf.

Es ist mir nach einiger Zeit auch gelungen, das Display über eine kleine 
Testhardware zum Laufen zu bringen.

Leider funktionierte das Display bei erneutem Flashen des verwendeten 
Mikrocontrollers zur Ansteuerung nicht mehr. Es wurde zu Beginn der 
gesamte Bildschirm weiß und mittlerweile lässt es sich nicht mehr 
ansprechen. Das Display braucht 700mA(!) und der Epson Controller 
S1D13700 wird heiß.

Mir ist jedoch nicht klar, wie das passieren konnte, da das Display ja 
bereits funktioniert hat (Ansteurungshardware wäre somit in Ordnung). 
Zwei Vermutungen:
1) Ist es möglich, dass der S1D13700 durch eine fehlerhafte Software 
zerstört werden kann? Der Grafik-RAM vom Display geht laut Datenblatt 
vom S1D13700 von der Adresse 0x0000-0x7FFF, danach kommen die Register. 
Wenn jetzt zum Beispiel durch eine fehlerhafte Zeichenfunktion ein 
setPixel() aufgerufen wird, das auf eine Adresse >0x7FFF (momentan noch 
fehlende Abfrage in setPixel(), die auf ungültige Adresse überprüft) und 
somit auf die Register zugreifen würde, kann das den Controller 
zerstören?
Im Datenblatt vom S1D13700 heißt es unter 10.2 Register Restrictions: 
All reserved bits must be set to 0 unless otherwise specified. Writing a 
value to a reserved bit may produce undefined results. Bits marked as 
n/a have no hardware effect.

2) Auf der Rückseite der Displayplatine befinden sich Löcher zur 
Befestigung. Diese haben Kontakt mit einer Fläche, die um das Display 
herum verläuft (siehe Anhang). Diese Fläche hat jedoch keinen Kontakt 
zur Masse. Ist es ein Problem, wenn diese Fläche durch Abstandsbolzen, 
die in den Befestigungslöchern verschraubt sind, mit Masse Kontakt 
bekommen? Es wäre möglich, dass dies kurz der Fall war (Abstandsbolzen 
an einer Massefläche der Testhardware angestoßen) und so der Controller 
defekt wurde.

Ich hoffe, dass mir jemand helfen kann, da ich noch ratlos bin wie der 
Controller defekt wurde, ich das Display aber so bald wie möglich wieder 
funktionstüchtig machen muss.

Lg Stefan

von Benedikt K. (benedikt)


Lesenswert?

Stefan Tschiggerl wrote:

> 1) Ist es möglich, dass der S1D13700 durch eine fehlerhafte Software
> zerstört werden kann?

Äußerst unwahrscheinlich.

> Im Datenblatt vom S1D13700 heißt es unter 10.2 Register Restrictions:
> All reserved bits must be set to 0 unless otherwise specified. Writing a
> value to a reserved bit may produce undefined results. Bits marked as
> n/a have no hardware effect.

Das sind sonstige (Test)Funktionen, aber zu einer Zerstörung dürfte 
keine führen.

> 2) Auf der Rückseite der Displayplatine befinden sich Löcher zur
> Befestigung. Diese haben Kontakt mit einer Fläche, die um das Display
> herum verläuft (siehe Anhang). Diese Fläche hat jedoch keinen Kontakt
> zur Masse.

Dieser Rand ist mit Pin 18 verbunden, und dieser sollte an Masse gelegt 
werden, um die Störungen der CCFL und um ESD abzuleiten.

> Ist es ein Problem, wenn diese Fläche durch Abstandsbolzen,
> die in den Befestigungslöchern verschraubt sind, mit Masse Kontakt
> bekommen?

Nein.

> Ich hoffe, dass mir jemand helfen kann, da ich noch ratlos bin wie der
> Controller defekt wurde, ich das Display aber so bald wie möglich wieder
> funktionstüchtig machen muss.

Wenn der Controller wirklich defekt ist, hilft nur ein neuer Controller.

Die häufigste Ursache dürfte die negative Displayspannung sein. Kannst 
du ganz sicher ausschließen, dass Pin 2 oder Pin 17 mit einer der 
Datenleitungen in Kontakt gekommen sind?

von Stefan T. (stefan90)


Lesenswert?

Benedikt K. wrote:

>
>> 2) Auf der Rückseite der Displayplatine befinden sich Löcher zur
>> Befestigung. Diese haben Kontakt mit einer Fläche, die um das Display
>> herum verläuft (siehe Anhang). Diese Fläche hat jedoch keinen Kontakt
>> zur Masse.
>
> Dieser Rand ist mit Pin 18 verbunden, und dieser sollte an Masse gelegt
> werden, um die Störungen der CCFL und um ESD abzuleiten.
>
>> Ist es ein Problem, wenn diese Fläche durch Abstandsbolzen,
>> die in den Befestigungslöchern verschraubt sind, mit Masse Kontakt
>> bekommen?
>
> Nein.

Pin 18 ist auf der Testplatine mit GND verbunden. Die äußere, umlaufende 
Fläche, mit der die Abstandsbolzen in der Abbildung verbunden sind, 
haben aber keinen Kontakt zu Pin 18 und auch sonst zu keinem der 
Anschlusspins vom Display.

> Die häufigste Ursache dürfte die negative Displayspannung sein. Kannst
> du ganz sicher ausschließen, dass Pin 2 oder Pin 17 mit einer der
> Datenleitungen in Kontakt gekommen sind?

Mit dem Versuchsaufbau wie ich ihn jetzt habe ist kein Kontakt. Leider 
könnte dies aber im Betrieb passiert sein. Habe gerade bemerkt, dass 4 
Befestigungsschrauben eben für die Abstandsbolzen nahe der Hardware 
liegen und kann nicht sicher sagen, ob die nicht auch einen Kontakt 
verursacht haben. Das wäre ein äußert blöder Umstand gewesen (zB 
Schraube an Stiftleiste geraten und Kontakt zwischen Pins hergestellt)

Sonst fällt mir keine Erklärung ein, jedoch soll der S1D13700 nicht 
gleich wieder defekt sein, sobald er getauscht ist, darum muss ich eben 
die genaue Ursache wissen.
Am Display wird zwar "nur" der S1D13700 heiß, meinst du aber, dass noch 
mehr beschädigt werden konnte und womöglich ein Tausch des Controllers 
alleine nicht reicht?

Lg Stefan

von Benedikt K. (benedikt)


Lesenswert?

Stefan Tschiggerl wrote:
> Die äußere, umlaufende
> Fläche, mit der die Abstandsbolzen in der Abbildung verbunden sind,
> haben aber keinen Kontakt zu Pin 18 und auch sonst zu keinem der
> Anschlusspins vom Display.

OK, dann hast du eine neuere Version von dem Display. Bei mir ist Pin 18 
mit dem Metallrahmen und den Bohrungen verbunden. Bei dir dürfte es dann 
nur mit dem Metallrahmen verbunden sein.

> Am Display wird zwar "nur" der S1D13700 heiß, meinst du aber, dass noch
> mehr beschädigt werden konnte und womöglich ein Tausch des Controllers
> alleine nicht reicht?

Der 13700 ist recht empfindlich, da er recht modern ist und somit in 
einem kleinen Prozess hergestellt wird. Es könnte zwar noch mehr auf dem 
Display kaputt sein, aber ich würde vermuten, dass der 13700 als 
empfindlichstes Bauteil sich geopfert hat. Außerdem ist er das einzige 
IC, das direkt mit der Außenwelt verbunden ist (mal abgesehen von dem 
Schaltregler der die -25V erzeugt).

von Stefan T. (stefan90)


Lesenswert?

Selbst der Metallrahmen hat bei meiner Version keinen Kontakt mehr zu 
dieser Fläche.

Ich werden mal den S1D13700 tauschen und hoffe dass es dann wieder 
funktioniert.

Danke für deine hilfreichen Antworten.

Lg Stefan

von Benedikt K. (benedikt)


Lesenswert?

Stefan Tschiggerl wrote:
> Selbst der Metallrahmen hat bei meiner Version keinen Kontakt mehr zu
> dieser Fläche.

Es kann sein, dass es zusätzlich noch einen Lötjumper gibt, den man 
schließen muss. Ich würde den Schließen um die großen Metallteile auf 
ein sauberes Potential zu bringen.

von Stefan T. (stefan90)


Lesenswert?

Es gibt mehrere solcher Lötjumper.
Man kann sowohl den Metallrahmen als auch die umlaufende Fläche auf 
Masse jumpern. Pin 18 kann man ebenfalls mit der Fläche bzw. 
Metallrahmen verbinden. Soll ich alle 3 Jumper schließen?

Was mir allgemein noch zum Display aufgefallen ist: Es wurde erst etwas 
angezeigt, nachdem Chip-Select auf high war bzw. es war sogar notwendig, 
dass CS nach jedem RD bzw WR Befehl von low auf high geht. War CS 
ständig auf low, wurde nie etwas angezeigt. Ist das eine Eigenheit vom 
Display oder vom S1D13700?

Weiters habe ich bemerkt, dass die Schreib- und Lesezugriffe eher 
langsam sind. Später soll das Display nämlich am XMEM vom Mega128 laufen 
(derzeit noch über Daten-PORT und Steuerleitungen selbst angesteuert), 
wodurch bei 16MHz bestimmt Waitstates notwendig sind. Ich hoffe nur, 
dass der Bus nicht zu schnell ist mit max. 2 Taktzyklen als Waitstates. 
Hast du Erfahrungen mit dem Display am externen Memory Interface?

Lg Stefan

von Benedikt K. (benedikt)


Lesenswert?

Stefan Tschiggerl wrote:
> Es gibt mehrere solcher Lötjumper.
> Man kann sowohl den Metallrahmen als auch die umlaufende Fläche auf
> Masse jumpern. Pin 18 kann man ebenfalls mit der Fläche bzw.
> Metallrahmen verbinden. Soll ich alle 3 Jumper schließen?

Ich würde Metallrahmen und und die Fläche mit Pin18 verbinden und dann 
auf der Hauptplatine an Masse legen.

> Was mir allgemein noch zum Display aufgefallen ist: Es wurde erst etwas
> angezeigt, nachdem Chip-Select auf high war bzw. es war sogar notwendig,
> dass CS nach jedem RD bzw WR Befehl von low auf high geht. War CS
> ständig auf low, wurde nie etwas angezeigt. Ist das eine Eigenheit vom
> Display oder vom S1D13700?

Beim 13700 ist mir das noch nicht aufgefallen (ich habe ehrlich gesagt 
aber auch nicht genauer danach geschaut), aber bei dessen Vorgänger dem 
13305 war das auch so. Andere Displays haben ein Status bis, das anzeigt 
ob der Speicher Zeit für neue Daten hat, beim 13305 hat das externe 
Interface Priorität und das Display wird mit 0en beliefert, solange der 
externe Bus aktiv ist.

> Weiters habe ich bemerkt, dass die Schreib- und Lesezugriffe eher
> langsam sind.

Was meinst du mit langsam? Fragst du die Busy Leitung ab, oder was 
dauert so lange?

> Später soll das Display nämlich am XMEM vom Mega128 laufen
> (derzeit noch über Daten-PORT und Steuerleitungen selbst angesteuert),
> wodurch bei 16MHz bestimmt Waitstates notwendig sind. Ich hoffe nur,
> dass der Bus nicht zu schnell ist mit max. 2 Taktzyklen als Waitstates.
> Hast du Erfahrungen mit dem Display am externen Memory Interface?

Ja, ich hatte den 13700 an einem mega8515 laufen. Gelesen habe ich nur 
die Register, aber Schreiben ging bei 16MHz ohne Busyabfrage und XMEM 
problemlos.

von Stefan T. (stefan90)


Lesenswert?

Ich frage die Busy Leitung derzeit nicht ab. Beim Read waren nach dem 
Befehl RD=low 4 nop notwendig, damit bei 8MHz und ATmega644 der Wert 
richtig eingelesen wurde (hab ich am auch gut am Logikanalyzer 
beobachtet)

Und deswegen meine Bedenken bei Verwendung des XMEM und 16MHz, da man 
max. nur 2 Systemtakte als Waitstates programmieren kann. Sobald das 
Display wieder läuft werd ich es am besten am XMEM testen und schauen 
obs geht.

Lg Stefan

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.