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

OP #7508182
Lesenswert?

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

Angehängte Dateien:
#7508190
Lesenswert?

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.

OP #7508192
Lesenswert?

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

#7508197
Lesenswert?

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

(Firma: 1984now) #7508545
Lesenswert?

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.

OP #7508600
Lesenswert?

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 :-(

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren