Flash über JTAG lesen, Adressierungsfehler? | phyCORE MPC5200B tiny

Zu bemerken ist, dass im ausgelesenen Image aller defekten module alle 512Byte 16Bit 0x0000 sind, ansonsten sind die Images der funktionierenden module Bitgleich (offensichtlich selbe SW Version)

Schreibe ich den Dump aus einem OK-Modul in ein defektes, dann bootet dieses leider immer noch nicht. Zurücklesen/Verifizieren kann ich, Image ist dann OK. Kann da ein defekter Bonddraht im Prozessor sein? 3 Defekte module haben jedoch denselben Fehler!?

Setzt UrJTAG denn die Chip Select Leitungen so wie es die für die Hardware richtig ist?

Ich denke das muss man selber machen, siehe "IPBI Control Register and Wait State Enable" im Datenblatt, speziell auch das Bit "Boot Enable".

Ich denke, es ist erfolgsversprechender, das Flash extern in einem Programmer auszulesen und in neue Flashes zu kopieren. So kann der Chip isoliert getestet werden, und Probleme auf der Leiterplatte können ausgeschlossen werden. Eventuell kannst Du Dir noch weitere Exemplare des Flash-Chips besorgen.

Die letzte Möglichkeit wäre, die Module zu Phytec zum Test zu schicken. Das werden die sicher nicht für lau machen, aber das hängt dann von Deinen Schmerzen ab.

fchk

Dieter S. schrieb:

Chip Select Leitungen so wie es die für die Hardware richtig ist?

Guter Punkt. Ich dachte zuerst, das hat ja keinen einfluss, da die Register nicht persistent sind. Aber wenn ich sie zum flash lesen und schreiben modifiziere, dann bekomme ich ggf mehr aus dem flash, denn nach dem reset ist Boot stop adress 0x80000.

Den Flash chip kann ich momentan schlecht kontatieren, da BGA. Habe hier einen TL866II Pro, der unterstützt nicht offiziell diesen flash, aber das ist einfacher paralell-adressierter flash oder?

Adapter habe ich nur für TSSOP und fädeldraht am BGA64 wird eine herausforderung. Aber ich bestelle mal einen Adapter.

Was ist mit dem "Backup" U-Boot (siehe phyCORE-MPC5200B tiny Hardware Manual), funktioniert das eventuell noch?

Dieter S. schrieb:

Was ist mit dem "Backup" U-Boot

Boot Pin auf HIGH bringt leider keinen Boot-Output. Darum meine annahme, dass der Gerätehersteller vielleicht alles gelöscht und ein Monoltithisches Baremetal Software einsetzt. Dazu passt nur nicht die ca. 15s Bootzeit. Jedoch könnte ich, wenn ich ein U-Boot Binary finde, das mal in den Flash schreiben und schauen wie ich weiterkomme.

Ich probiere gerade MBAR zu finden und CS0 Stop adress zu ändern. Aber in 0x8000 0000 (init MBAR addr) steht nicht 0x0000 8000 sondern 0x0000 auch wenn ich was anderes reinschreibe

Flip B. schrieb:

Ich probiere gerade MBAR zu finden und CS0 Stop adress zu ändern.

MBAR steht beim e300 in SPR311 (Special-purpose Register). Ich würde erwarten dass UrJTAG auf die SPRs zugreifen kann.

Ich habe neuigkeiten. Ich habe den flash bisher auf dem zugehörigen Motherboard aus dem Wechselrichter gelesen. Dort ist noch ein FPGA, der offensichtlich mit am Bus hängt. Nun habe ich in höheren Flash-bereichen noch mehr Daten gefunden, die jedoch nach Müll aussehen. Eventuell der Config-Bitstream aus dem FPGA?

Ich lasse wohl nochmal ein komplettes Flashdump laufen, dauert leider mit meinem setup ca. 5h30min

Hier das FPGA-Motherboard

Ohne Motherboard komme ich an alle Flashbereiche und bekomme plausible daten raus. Im höchsten Block liegt den strings zufolge ein U-Boot. Ich kann jedoch nicht mehr als 0x100000 (1MByte) am stück lesen, sonst kommt nur noch FFFF. Eventuell hat das auch gar nichts mit dem Motherboard zu tun, nur ein Bug im UrJtag flash treiber.

Der FPGA auf dem Motherboard könnte im Adressraum des MPC5200B eigene IO Register einblenden. Unter der Annahme dass der FPGA nicht defekt ist stellt sich die Frage ob UrJTAG eventuell den Flash falsch erkennt weil es durch den FPGA im Adressraum durcheinander kommt.

ich habe jetzt einen kompletten dump eines OK board sowie U-Boot von einem NOK modul gelesen. Das Image vom NOK hat die gleichen defekten 0x0000 bytes wie ich im niedrigeren Adressraum beibachtet hatte.

Überschreiben des U-Boot klappt schonmal, das ursprünglich defekte Board lässt schonmal die Boot-Leds blinken. Jetzt ist vermutlich noch das jiffs defekt, das möchte ich aber über uboot uart überschreiben, hoffe das geht schneller.

Ich konnte ein Gerät wiederbeleben, hielt leider nicht lange. 2x Booten und es war wieder tot. Werde jetzt mal neue Flash-Chips bestellen.

Auf dem Board läuft MQX von NCP ....

Ich habe einen BDI2000 mit bdigdb cop 1.33 drangeklemmt; das ist das lt. Phytec auch das Gerät, dass vor ~20 Jahren bei der Entwicklung benutzt wurde. Netterweise bekam ich auch die cfg für das Modul, hatte selber ein paar Probleme mit dem Setup des SDRAM-Controllers, fehlten wohl ein paar Bits in meiner cfg. Praktischerweise haben die alten SR-Boards bis 2.07 noch eine schöne 2.54mm-JTAG-Wannenbuchse. Mit dem 2mm-Anschlüssen komme ich nicht weit, finde keine passenden Stecker dafür.

Das Debugging ist etwas mühsehlig, der Prozessor scheint in eine Endlosschleife bei 0xfff0b4f0 zu geraten. Hab's dann erstmal gelassen... Allerdings war es kein Problem, inzwischen fünf Module zumindest im Trockenen an einem PMU-Board wieder an's Fliegen zu bekommen. Flash löschen und ein komplettes Image drüberflashen. Hatte da vorher noch das Datlog frisch formattiert.

Ich muss die noch im WR selber prüfen, und vielleicht auch eine Zeitlang im Labor laufen lassen ("hielt leider nicht lange. 2x Booten") ...

Meine Vermutung ist, dass wir sowas wie "over erasure" auf dem NOR-Flash haben. Das scheint zumindest eine gute Erklärung für seltsame Korruption im Flash. Die korrupten Daten habe ich runtergeladen, muss mal schauen, ob sich da in der Breite ein ähnliches Muster von defekten Daten findet.

Noch eine Erkenntnis: den Datlog-Bereich ab 0xff200000 kann man in 128kB-Blöcken löschen, die der Chip neben den 32kB-Blöcken unterstützt. Das klappt (am Anfang) des restlichen Flashbereich nicht; löschen von 128kB scheint dort nur die ersten 32kB zu löschen.

Was bekomm ich fürs auslesen und programmieren deines Flashes PC28F128P33B, EZBGA64?

Nochmal eine Zwischenmeldung: Ich habe jetzt 24 Module überprüft und neu geflasht; 7 davon waren wirklich defekt, SDRAM kaputt/nicht ansprechbar, Flash überhaupt nicht ansprechbar, und ein paar Flashspeicher mit versetzten Zugriffmustern (öfters 32bit breite Felder von meist 0x20, manchmal 0x10, früher aus dem Flash) die anderen 19 scheinen zu funktionieren...

Ich lese gespannt mit. Hatte damals nach erfolglosem Tausch des Flash aufgegeben, da ich eventuell lose bonds im MPC vermutete, Aber SRAM ist auch eine Spur. Hast du die PN mit meiner mailadresse bekommen? Vielleicht sind genau diese Module nun bei dir gelandet, wir können mal die MACs abgleichen.