Ich poste jetzt mal parallel zu meinen Bemühungen das Problem zu beheben hier im Forum. Vielleicht hat ja jemand ein ähnliches Problem oder gar eine Lösung dazu. Gegeben ist: ST ST STM32F4-Discovery Board mit STM32F407VG Embest Discover More STM32F4DIS_BB Board dazu gehörendes LC-Display (Hersteller unbekannt, wird aber im bündle bei Farnell verkauft) IDE: CooCox 1.7.6 GCC Toolchain: gcc-arm-none-eabi-4_8 Das Programm füllt nach der Initialisierung das Displayram komplett mit 0x0000 (schwarz). danach wird der Text "The quick Brown..." usw. Displayfüllend ausgegeben und in der Main-Loop wird an zwei Positionen der Zählerwert einer uint16_t Variable ausgegeben - mehr nicht. Im linken Bereich treten nach wenigen Sekunden und immer nur im Bereich von 96 Pixeln vertikal merkwürdige "Ghostpixel" auf. Es sieht fast so aus, als wenn Pixel aus dem zuvor geschriebenen Text willkürlich kopiert / verschoben werden. Drehe ich das Display um 180° (Register 0x01, RL=1, TB=1) wandern auch die Pixelfehler auf die andere Seite mit. Das Display ist über den FSMC Controller am STM32 angeschlossen. Initialisierung des Disp. im Moment nach dem Datenblatt vom SSD2119 Seite 83. Ich habe bereits mehrere Initialisierungsoptionen probiert. einige davon hier aus dem Forum, andere von unterschiedlichsten Quellen - das Ergebnis bleibt dasselbe. Ich habe auch unterschiedliche Timings ausprobiert und den STM32 ohne SystemInit() laufen lassen sodass die im Datenblatt beschriebenen Zeiten mit mehr als das Zehnfache eingehalten werden. Ich glaube so langsam nicht mehr an einen Softwarefehler, deswegen bin ich nun auch Hardwaremäßig auf der Suche. Ich hatte diverse Signale schon mal am Oszi - leichte Überschwinger, nichts besorgniserregendes. Trotzdem habe ich das 40-Polige Flachbandkabel mal auf 1/4 der vorherigen Länge gekürzt und diverse GND Pins mit dem GND Plane verbunden. Veränderung war aber unwesentlich. Auf dem BB Board sitzen 22Ohm Serienwiderstände in den Signalen. Sollte aber alles kein Problem sein da ich das Display bis zum im Datenblatt angegebenen Timing ansteuern kann, ohne das sich etwas verändert. Werde ich zu schnell, bleibt das Display wie erwartet einfach weiß. Was mich ja wundert ist, das an der Stelle wo die Pixelfehler auftreten ja gar nicht geschrieben wird. Der Text wird EIN Mal vor der Mainloop ausgegeben und dann nur noch die beiden Zähler links oben und rechts unten. Lasse ich den Zähler nur rechts unten ausgeben, passiert nichts. Erst ab einer Ausgabe ab Position X<=95 geht das mit dem Pixelmüll los. Vielleicht hat ja jemand einen hilfreichen Tipp für mich weil "so" macht das programmieren der Grafikroutinen im Moment nicht wirklich Laune. Besten Dank.
Angehängte Dateien:
-
DM-LCD35RT.jpg
150 KB
Der Text ist zu lang für das GLCD. Wo soll der denn hingeschrieben werden wenn eine Zeile nicht reicht?
Torsten S. schrieb: > Der Text ist zu lang für das GLCD. Wo soll der denn hingeschrieben > werden wenn eine Zeile nicht reicht? Der Text ist nicht zu lang und selbst wenn er es wäre, würde der GDRAM Counter weiterzählen und der restliche Text um ein Pixel nach unten versetzt weiter geschrieben werden. Wenn er das Ram-Ende erreicht, passiert nix, weil das Display wegen der Window-Size Einstellung einfach ignoriert. Abgesehen davon ist der Text ja auch lesbar und in Ordnung solange danach nichts geschrieben wird.
1 | for(i=0;i<240;i+=26){
|
2 | UB_Font_DrawString(0,i,"The quick brown fox jumps over the lazy ",&Arial_8x13,RGB_COL_YELLOW,RGB_COL_BLACK); |
3 | } |
Ich kenne diesen Effekt nur von wackeligen Kontakten beim Aufbau mit Jumperkabeln.
Möchte ich ausschließen da das Flachbandkabel ordentlich stramm auf der Stiftleiste sitzt. Aber das kann ich ja ggf. nochmal alles nachlöten. Allerdings hätte ich dann aber auf dem Oszi auch was wackeln sehen müssen. Nachtrag: nur zum Verständnis - das Bild zeigt das Display nach einigen Minuten Laufzeit. das sieht nicht direkt am Anfang so aus sondern es "lösen" sich mit der Zeit so langsam aber sicher einige Pixel.
:
Bearbeitet durch User
Hi, in welchem Mode wird das Display betrieben (mit oder ohne HSync,VSync-Signalen ?) ich würde zum Test mal den Display-Inhalt wieder zurück in die CPU lesen und als Bitmap zum PC (oder auf SD-Karte) schreiben dann sieht man ob der "müll" im Grafik-RAM steht oder ob das Display falsche Werte anzeigt event. ein Problem mit der Spannungsversorgung/Strom vom Display. sieht auf jeden Fall "komisch" aus P.S. spielt die Schriftfarbe deiner Zählerwerte eine Rolle bei dem Fehler also kommt der Fehler z.B. bei Schrift=Weiß und bei Schrift=Schwarz kommt er nicht ?
:
Bearbeitet durch User
Uwe B. schrieb: > in welchem Mode wird das Display betrieben > (mit oder ohne HSync,VSync-Signalen ?) ohne - Register 0x11 (Entry Mode) = 0x6830 -> DenMode=1 Beim Default wert des Datenblatt 0x6320 das Gleiche > ich würde zum Test mal den Display-Inhalt > wieder zurück in die CPU lesen und als Bitmap > zum PC (oder auf SD-Karte) schreiben > dann sieht man ob der "müll" im Grafik-RAM steht > oder ob das Display falsche Werte anzeigt Das dauert einen Moment, weil ich dazu erst mal eine Rückverbindung zum PC herstellen muss. Habe zwar auf dem STM32F4DIS_BB Board eine RS232 drauf, allerdings mit männlicher SubD9 und keinen genderchange oder Nullmodemkabel zur Hand ;) > event. ein Problem mit der Spannungsversorgung/Strom > vom Display. Vermute ich leider auch. Auf der +5v und der +3V Leitung habe ich beim Schreiben auf das Display einen ripple von ca. +/- 150mV auf dem Oszi gesehen. Die Leitungen sin halt auch recht lang. Erst das 40 Pol. Flachbandkabel und dann auf der Platine noch mal lange Leitung bis zum ZIF Connector ohne parallele GND Leitungen - ungünstiges Layout, wird aber leider so verkauft. > sieht auf jeden Fall "komisch" aus ja, unschön - will ich weg haben > P.S. spielt die Schriftfarbe deiner Zählerwerte eine Rolle bei dem > Fehler > also kommt der Fehler z.B. bei Schrift=Weiß und bei Schrift=Schwarz > kommt er nicht ? Schriftfarbe ist egal - schwarz, Magenta, grün etc. immer das selbe Ergebnis. Ich setzt mich mal an das Programm zum zurück lesen des Display RAMs.
Hi ich hab das selbe Board und verwende die selbe ide ich kann dir am Abend mein testprogramm hier hochladen dann kannst du sehn ob es ein hardwarefehler ist oder nicht.. Bei funktioniert es prima! Tolles Board!
Fox schrieb: > Hi ich hab das selbe Board und verwende die selbe ide ich kann dir am > Abend mein testprogramm hier hochladen dann kannst du sehn ob es ein > hardwarefehler ist oder nicht.. Das klingt super! Ich entseuche derweil mal mein Programm und leg dass dann im Gegenzug ebenfalls hier ab zwecks Gegencheck. Ist im Moment etwas durcheinandergewürfelt und nicht wirklich hübsch anzusehen ;) > Bei funktioniert es prima! Tolles Board! Ja, finde ich auch - lag viele Monate unbenutzt im Schrank rum weil ich keinen Anfang gefunden habe. Und als ich bei Keil wegen IDE angefragt habe, hab ich mich erst mal hingesetzt - die wollten irgendwas um die 11K EUR, da hab ich's dann erst mal gelassen.
Im Anhang nun die Software mit der es bei mir zum Pixelmüll kommt. Ich hab den ganzen "Versuchskram" in der Init Routine des SSD2119 auskommentiert stehen lassen für Versuchszwecke.
@Fox Denkst Du noch an mich? ;O) Vielleicht hat ja auch wer anders noch exakt die gleiche Entwicklungsumgebung und könnte einfach mal meinen Source probieren und mir berichten.
Hat sich erledigt. Habe die original INI Routine von ST genommen. Ergebnis: a) keine Pixelfehler mehr (Stichwort VcomH) b) DOPPELT so schnell danke für's Mitlesen
Hallo, habe gerade Deinen Post gefunden, ermutigt mich auch wieder mal an mein Problem zu setzen. Ich habe den gleichen Aufbau, aber ein etwas anderes Verhalten. Ich habe nach dem Start des Prg. am unteren Bildschirmrand ein etwa 6-7mm breiter Pixelsalatstreifen, der Rest läuft wird aber mit der Laufzeit des Programms auch immer schlechter. Vielleicht hast Du ja jetzt ein Testprogramm, das Du hochladen oder mir schicken könntest, oder ein etwas genauerer Hinweis auf die INI Routine von ST ? Danke und Gruss Daniel
Problem gefunden. Einstellungen im system_stm32fxx.c waren falsch
1 | #define PLL_M 8
|
2 | #define PLL_N 288
|
3 | #define PLL_P 2
|
4 | #define PLL_Q 6
|
5 | |
6 | uint32_t SystemCoreClock = 144000000; |
Mit 168Mhz gibt es Fehler auf dem Display.
Guido .. schrieb: > Hat sich erledigt. > > Habe die original INI Routine von ST genommen. Ergebnis: > > a) keine Pixelfehler mehr (Stichwort VcomH) > b) DOPPELT so schnell > > danke für's Mitlesen Hallo Guido, ich stehe aktuell vor einem ähnlichen Problem, dass nach gewisser Zeit Pixelmüll in einem Bereich entsteht, obwohl der Bereich nciht verändert wurde. Könntest du mir hier die verwendete INI Routine hochladen bzw. den Link darauf? Danke
Daniel B. schrieb: > Problem gefunden. Einstellungen im system_stm32fxx.c waren falsch > [c] > #define PLL_M 8 > #define PLL_N 288 > #define PLL_P 2 > #define PLL_Q 6 Grundsätzlich empfiehlt es sich, das Reference Manual zu lesen: Caution: The software has to set these bits correctly to ensure that the VCO input frequency ranges from 1 to 2 MHz. It is recommended to select a frequency of 2 MHz to limit PLL jitter. Also: PLL_M = 4, PLL_N = 144
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.