Fehlersuche bei Blaupunkt Radio/Navigationssystem (kein Bild)

[Olli Z. (z80freak)]

Ich tüftle immer noch an einem Problem das ich hier ein 
Radio/Navigationssystem habe welches grundsätzlich funktioniert, aber 
kein Bild anzeigt. Da ich glücklicherweise noch ein baugleiches, 
funktionierendes Gerät habe war mein erster Ansatz erstmal die 
Fehlergruppe durch Komponententausch einzugrenzen. Das Gerät hat ein 
Mainboard, ein Grafikboard an dem u.a. das farbige LCD-Display 
angeschlossen ist und ein Keyboard auf dem die Hintergrund-LEDs, 
Drehencoder und Tasten befestigt sind.

Inzwischen weis ich das das Problem auf dem Grafikboard vorliegt. Man 
kann das Grafikboard auf zwei am Mainboard vorgesehene Steckkontakte 
aufstecken und inzwischen erkenne ich an der Stromsignatur ob es 
funktioniert oder nicht. Betreibt man nur das Board liegt die Primäre 
Stromaufnahme bei ca. 720 mA (14V). Brückt man den Ein-Taster (ON_TIPPER 
MP auf der Platine gegen GND) steigt der Stromverbrauch beim 
funktionierenden Grafikboard auf ca. 820 mA, beim defekten Grafikboard 
geht es nur ca. 10 mA hoch.

Als erstes habe ich natürlich sämtliche Spannungsregler auf dem Board 
überprüft. Die arbeiten alle einwandfrei. Der Teil zur Erzeugung der 
LCD-Spannung und Hochspannung für die CCFL-Hintergrundbeleuchtung wird 
nicht aktiviert, aktiviere ich diese jedoch manuell durch überbrücken 
geben diese einwandfreie Spannungen ab (beim CCFL Inverter habe ich nur 
primärseitig die Taktung am Trafo gemessen und mit dem funktionierenden 
Gerät verglichen).

Nachdem ich elektrisch keinen Fehler finden konnte habe ich sowohl das 
Flash (Betriebssystem der Grafikkarte) als auch das ECS4 Flash (IP des 
Cyclone-III FGPA) gegenseitig gewechselt. Das hat gezeigt das beides 
Flash intakt und funktionierende Programmierung enthalten.

Ich erkenne am SDRAM-Chip, am Flash und an der Cyclone FPGA auch 
Datensignale, also Aktivität, aber leider nicht an den IO-Ports welche 
u.A. die Spannungsregler aktivieren.

Die Grafikkarte wird über einen 16-Bit Datenbus von der OMAP-CPU auf dem 
Mainboard mit Bildinformationen versorgt (RGB) sowie mit weiteren 
Steuersignalen (H/V-Sync, etc.). Auf der intakten Grafikkarte erkenne 
ich das diese Signale anstehen, auf der defekten sind die 
Grafikdatenleitungen alle LOW.

Zusätzlich gibt es noch einen SPI Kontrollkanal über den die auf dem 
OMAP laufende Applikation vermutlich der Grafikkarte Steuerbefehle 
sendet und Rückmeldungen erhält. Über die Grafikkarte wird auch das 
Keyboard angeschlossen, also gehen wohl auch die Tastendrücke etc. 
darüber zurück an die App auf dem OMAP.

Dieses SPI Interface habe ich mir mal genauer angeschaut. Ein 
exemplarischer Schnappschuss ist beigefügt. Dazu habe ich (zum ersten 
Mal) die LA-Option meines Siglent 2104X genutzt und erstmal die 
funktionierende Grafikkarte gescannt. Bei den Signalen bin ich mir schon 
sehr sicher, aber das was ich da sehe finde ich merkwürdig.

Der OMAP5948 (OMAP5912) verwendet eine Hardware-SPI (MIBSPI1 und 
/SPI_CS0) für die Kommunikation (3,3V Digital-Pegel). Dadurch das CLK im 
Ruhezustand HIGH ist vermute ich das es sich um den SPI Mode 2 oder 3 
handeln muss (CPOL=1).

Aus den Datagrammen werde ich aber noch nicht schlau. Auch das sich 
zwischen dem SPI-Decoder meines Siglent SGS2104X mit Digitaleingängen 
und einem Saleae so große Unterschiede abzeichnen, vom CLK angefangen 
bis zu den Daten. Was mich auch etwas irritiert ist das MISO und MOSI 
gleichzeitig Daten übertragen. Das ist zwar per Prinzip machbar, aber 
ich hätte hier eher einen Request/Answer Kommunikationsstil erwartet.

Leider habe ich auch keine Idee wie ich die Funktion des FPGA prüfen 
soll? Ich sehe auf dem Oszi das der ECS4 Daten abgibt und danach passiv 
wird. Dies würde er ja nur tun wenn die FPGA diese Daten beim 
bootvorgang abruft, also kann sie ja nicht ganz tot sein.