Hilfe bei Fehlersuche an einem (Linux?) Embedded System, das nicht startet

[Christian S. (chris02)]

Hallo zusammen,

gerne würde ich mich ein wenig in die Fehlersuche bei Embedded Systemen 
einarbeiten und auch mal das Thmea BGA löten vertiefen. Ich habe mir 
drei Siemenes Solarwechselrichter (PVM20) besorgt.

Davon starten zwei nicht und einer läuft Problemlos.
Der Wechselrichter hat eine Steckbare Platine, mit µC, RAM, Flash etc.. 
Genauerer Aufbau dazu in dem angehangenem Bild.

Tausche ich diese Platine, vom i.O. Gerät in die beiden defekten Geräte, 
laufen die defekten Geräte auch. Der Fehler liegt also definitiv an 
dieser Platine.

Bei der defekten Platine gehen nur die LEDs vom Wechselrichter an, das 
Display bleibt leer und mehr passiert nicht.

Meine Vermutung ist, dass ein Linux Betriebssystem genutzt wird. Ich 
habe mir das EEPROM ausgelesen und im Hex Editor angesehen. Dies sieht 
mir nach Linux aus, bin mir damit aber nicht sicher. (EEPROM im Anhang)

Verbaut sind auch noch zwei, vermutlich, Stepdowns. Dazu finde ich aber 
keine Datenblätter. "LADT" scheint das Marking zu sein, da die Codes 
darunter auf den anderen beiden Platinen andere sind. Das wird Date Code 
etc. sein.
Wenn ich den StepDown kennen würde, könnte man diesen nochmal gezielter 
durchmessen.

Verbaut ist ein NXP MPC5200B
(Datenblatt: 
https://www.mouser.de/datasheet/2/302/MPC5200BDS-3138637.pdf)

Am Rand der Platine sind Kontakte nach außen geführt, die mir so 
scheinen, dass sie in der Produktion zum Programmieren genutzt werden. 
Die Kontakte auf der Ober- und Unterseite sind nicht durchkontaktiert.

Bei einer Platine habe ich den Flash ausgelötet und wollte gucken ob die 
Pins zum Programmieren auf diese Stiftleiste gehen, was ich bis jetzt 
noch nicht verifizieren konnte.
Ein T56 Programmer ist vorhanden, allerdings noch kein passender BGA 
Adapter.

Mein Wunsch wäre es:
 - die i.O. Platine sollte nachher auch noch i.O. sein
 - eine Platine kann zum reverse engineering genutzt werden
 - die Dritte Platine sollte zum Schluss auch laufen

Nun meine Frage an euch: Wie geht man am besten bei der Fehlersuche vor? 
Welche Bauteile sind die, die am ehesten Ausfallen? Gibt es ggf. Debug 
Möglichkeiten?

Vielen Dank und viele Grüße
Chris

[Stefan F. (Gast)]

Christian S. schrieb:
> Wie geht man am besten bei der Fehlersuche vor?

Schaltplan besorgen, sowie die sonstige technische Doku dazu.

Aber ich fürchte, der Hersteller hat da wie üblich ein Wegwerf-Produkt 
geschaffen. Das soll man nicht reparieren können.

[Rüdiger B. (rbruns)]

Das Linux ist wenn überhaupt im 128 kb Flash. Der Chip verfügt über 
Serielle JTAG und UBS Ports, über einen von denen wird er Programmiert 
bzw. spuckt Informationen aus.

[Stefan S. (chiefeinherjar)]

Christian S. schrieb:
> Ich habe mir das EEPROM ausgelesen und im Hex Editor angesehen. Dies
> sieht mir nach Linux aus, bin mir damit aber nicht sicher. (EEPROM im
> Anhang)

Mal aus ehrlicher Neugierde, woran erkennst du bzw woraus schließt du 
aus dem Hex, dass es sich um ein Linux handelt?

Ich zweifle eher daran, da es sich bei dem Code im I2C EEPROM um das 
Betriebssystem (Linux?!) handelt.
Warum so eine "langsame" Schnittstelle für Programmcode verwenden?
Ich bin da eher bei Rüdiger.

Rüdiger B. schrieb:
> Das Linux ist wenn überhaupt im 128 kb Flash. Der Chip verfügt über
> Serielle JTAG und UBS Ports, über einen von denen wird er Programmiert
> bzw. spuckt Informationen aus.

[Christian S. (chris02)]

Danke für eure , Rückmeldungen. Ich gehe nicht davon aus, dass das Linux 
in dem EEEPROM ist, dafür ist es zu klein. Sondern wenn im Flash, da bin 
ich bei euch.
Wenn ich das richtig interpretiere, ist im EEPROM aber die Aufteilung 
des Flash drin und das sieht mir nach Linux aus. EEEPROM ist angehangen, 
bin gerne für andere Meinungen offen.

Der Controller hat keinen eigenen Flash, habe ich das richtig gesehen? 
Nur ein RAM.
Debug Schnittstelle, klar das hätte ich auch drauf kommen können. Danke 
:-) Muss Mal genauer ins Datenblatt gucken, was man da braucht. Dann 
geht's weiter die passenden Pins raus zu finden.
Wird der Flash dann auch über den uC Programmiert oder eher der Flash 
direkt?

Viele Grüße
Chris

[Frank L. (florenzen)]

Christian S. schrieb:

[...]
> Wenn ich das richtig interpretiere, ist im EEPROM aber die Aufteilung
> des Flash drin und das sieht mir nach Linux aus. EEEPROM ist angehangen,
> bin gerne für andere Meinungen offen.
[...]
> Viele Grüße
> Chris

Für mich sieht das nach den Parametern für den Bootloader aus (uBoot).
Der wartet 3 Sekunden in denen du auswählen kannst, ob du aus dem Flash 
oder per Tftp booten willst.
Außerdem ist schwer zu vermuten daß das Ding eine serielle Konsole mit 
115200 Baud hat mit der du den Bootloader bedienen, sowie den 
Bootvorgang beobachten kannst.
Die Pins für die Konsole gilt es zu herauszumessen!

Gruß,
f

[Rüdiger B. (rbruns)]

Frag mal bei Refu an ob die ein Firmwareupdate machen.

[Ob S. (Firma: 1984now) (observer)]

Christian S. schrieb:

> Meine Vermutung ist, dass ein Linux Betriebssystem genutzt wird.

Das ist wohl so.

> Ich
> habe mir das EEPROM ausgelesen und im Hex Editor angesehen. Dies sieht
> mir nach Linux aus, bin mir damit aber nicht sicher. (EEPROM im Anhang)

Das sind nur Konfigurationsdaten für einen (TFTP-) Bootloader, nicht das 
eigentliche OS. Das liegt sicherlich im Flash.

> Wird der Flash dann auch über den uC Programmiert oder eher der Flash
> direkt?

Sicher über den µC. Ich kenne jedenfalls keine Flash-Bausteine mit 
eingebautem IP-Stack.

[Christian S. (chris02)]

Danke für die Infos. Denke ich habe erstmal wieder genug um weiter zu 
machen.
Zuerst werde ich den seriellen Ansatz versuchen. Zum Thema U-Boot, 
Firmware Dump etc findet man auf YouTube eine Menge.

Parallel werde ich mal nach einem JTAGer gucken. Im wesentlichen geht es 
erstmal darum die passenden Pins raus zu finden. Ggf. bekomme ich ja 
schon einige Infos, z.B. wo es beim Booten klemmt, wenn ich dem 
Bootloader lausche.

@Rüdiger
Update bei den Siemens nur offiziell über Siemens :-(

[Rüdiger B. (rbruns)]

Christian S. schrieb:
> Update bei den Siemens nur offiziell über Siemens :-(

oder bei authorisierten Servicestellen z.B. Refu ( laut PV Forum )