Hallo zusammen, ich lese/schreibe seit ner Weile einen 9S08DZ96 (Flash und Eeprom) ohne Probleme. Leider ist letzte Woche mein Programmer (ein China Clone eines XProg-M) gestorben. Ist wohl ein bekanntes Problem, das ein ATMega64A im Inneren ein Zertifikat verliert und dann geht nichts mehr. Ich hab einen neuen ATMega in CN bestellt, aber das dauert. So lange kann ich nicht warten. Frage: wie kann ich den 9S08DZ sonst noch lesen & schreiben? Ich hab seit Ewigkeiten ein USBDM (Basierend auf 9S08JS16 auch aus CN), aber dieses noch nie erfolgreich verwendet. Ich hab das ganze Wochenende verzweifelt versucht, damit den µP anzusprechen, aber nie eine Antwort bekommen. Selbst das Detektieren des Target schlägt fehl. Ich vermute ich mach irgendwas generell falsch. Hat jemand einen Tipp für mich? VG Ralf
Angehängte Dateien:
-
IMG_7988.jpg
230 KB
:
Bearbeitet durch User
Angehängte Dateien:
-
usbdm_1.jpg
47 KB
...Topic kann geschlossen werden, weil der Benutzer zu dämlich ist, oder 0204 Widerstände nicht mehr mit dem Auge erkennt.
Die widerlichen Details waeren schon interessant. So einen (Spezial-)BDM habe ich auch und noch nie benutzt.
...auf dem zweiten Bild fehlt R13. Muss ein Produktionsfehler gewesen sein, aber ohne den kommt kein BKGD Signal durch. Inzwischen konnte ich zumindest schon mal eine Hälfte des EEPROM von 0x3000 bis 0x3FFF auslesen. Aber wichtiger wäre das Lesen und Schreiben des gesamten Flash Bereichs.... aber das scheint alles andere als einfach im Vergleich zum XProg Wenn mir da nicht noch was einfällt oder mir jemand einen guten Tipp geben kann, muss ich drei Wochen auf die Ersatz-Lieferung aus China warten.
Ralf G. schrieb: > > Aber wichtiger wäre das Lesen und Schreiben des gesamten Flash > Bereichs.... aber das scheint alles andere als einfach im Vergleich zum > XProg Wenn man in den "Memory Options" von USBDM die Pages richtig einstellt sollte der Zugriff auf den gesamten Flash funktionieren.
Danke Dieter, aber wie mache ich das richtig? Bislang habe ich versucht "flat" zu lesen, aber da kommen nur die ersten 48k korrekt Paged mit jeweils Register Address 0 und 1 kommen die gleichen (ersten) 48k
:
Bearbeitet durch User
Ralf G. schrieb: > Danke Dieter, aber wie mache ich das richtig? > Das hängt vom Chip ab. Man findet ich Netz Beispiele, die muss man dann eventuell auf den jeweiligen Chip anpassen, den man auslesen will. Ich habe das schon mit USBDM gemacht, das funktioniert (zumindest mit den Chips, die ich auslesen wollte). Mit XPROG geht es einfacher, aber das Ergebnis war das selbe. Hier steht ein wenig dazu bzw. zeigt in etwa die Richtung: https://community.nxp.com/t5/OSBDM-and-TBDML/How-to-read-flash-and-EEPROM-with-USBDM-from-HCS08/td-p/402458
Nochmal Danke! Tatsächlich hatte ich diesen Beitrag schon gefunden und auch mehrfach gelesen. Ich konnte mir nur keinen Reim drauf machen. Das Proz-Datenblatt hat mir bislang leider auch nicht weiter geholfen. Ich weiss nur, das wenn ich mit meinen (falschen) Einstellungen lese, wird mir auch der EEprom Inhalt irgendwann oberhalb von 0x0FFFF mit ausgelesen. Ohne das ich einen vollständigen Dump vom Flash habe, weiss ich auch nicht, wie mein bin File nach der Konvertierung in S19 aussehen muss.
:
Bearbeitet durch User
Ralf G. schrieb: > > Tatsächlich hatte ich diesen Beitrag schon gefunden und auch mehrfach > gelesen. Ich konnte mir nur keinen Reim drauf machen. Das > Proz-Datenblatt hat mir bislang leider auch nicht weiter geholfen. > Nur um sicher zu sein: Die USBDM Version ist halbwegs aktuell? Da wurde ja auch immer wieder etwas verbessert, auch was die Unterstützung der Pages betrifft.
Angehängte Dateien:
-
MemoryMap.JPG
71 KB
Ja, ist die aktuelle USBDM Version, basierend auf JS16. PPAGE für den DZ96 ist lt Datenblatt bei Adresse 78 Jetzt habe ich nur noch keine Ahnung, was die "initializion commands" machen sollen.
:
Bearbeitet durch User
....da ich hier irgendwie nicht weiter komme (Wie kann man bei NXP ein Tool programmieren, aber keinerlei Doku dazu anbieten? Der Memory Dumper bleibt für mich ohne Anleitung kryptisch.) Anderer Lösungsversuch: Ich habe ein intakten Memory Dump vom Flash mit einem Xprog-M, den ich auch in der Vergangenheit erfolgreich auch wieder zurück gespielt habe. Wie bekomme ich die Daten OHNE XPROG wieder in den Chip? Die Programmer SW von USBDM will ein S19 File und kein XProg BIN File.... 1. kennt jemand ein Programm was einen bin File korrekt auf einen 9S08DZ96 schreiben kann 2. kennt jemand eine Möglichkeit, wie ich aus dem bin ein passendes S19 machen kann, das vom USBDM Programmer akzeptiert wird? Meine Versuche mit srec den File zu konvertieren, waren bislang nicht erfolgreich. VG Ralf
Ralf G. schrieb: > ....da ich hier irgendwie nicht weiter komme (Wie kann man bei NXP ein > Tool programmieren, aber keinerlei Doku dazu anbieten? Der Memory Dumper > bleibt für mich ohne Anleitung kryptisch.) Für USBDM gibt es den Sourcecode. Zur Not kann man sich das im Detail ansehen und bei Bedarf auch anpassen.
… je nachdem wie viel ich da lesen und lernen muss, kann ich auch die drei Wochen warten :/
Angehängte Dateien:
Ralf G. schrieb: > … je nachdem wie viel ich da lesen und lernen muss, kann ich auch die > drei Wochen warten :/ So schwierig ist das jetzt auch nicht. Als Beispiel wie man mit USBDM einen MC9S08LH64 ausliest siehe das Bild. Man muss lediglich die Flash Pages im Paging Window (0x8000..0xBFFF) eintragen. Der MC9S08LH64 hat vier Pages. Die Bits 16..23 (also das oberste Byte) der Adresse ist für das Paging Register. Ausserdem das PPAGE Register des jeweiligen Chip eintragen, beim MC9S08LH64 liegt PPAGE auf 0x0030.
Dieter, you made my day .... mal wieder! Dankeschön!! Da lag mein Gedankenfehler: ENTWEDER liest man linear ODER Paged. Ich hab versucht "gemischt" zu lesen, das kann natürlich nicht funktionieren. Einzige Änderung: der S08DZ96 hat das PPAGE bei 0x78 Ich hab jetzt alle 5 Pages des DZ96 ausgelesen und mit dem daraus entstandenen S19 File ein Verify im Programmer gemacht: voila alles ok!!! Das ist ein Quantensprung (für mich). Jetzt muss ich nur schauen, wie ich aus dem bin file ein entsprechendes S19 zusammen bastel. Mal sehen wie lange ich dafür brauche. Nochmal dankeschön bin hier hin!!! VG Ralf
:
Bearbeitet durch User
Ralf G. schrieb: > > Jetzt muss ich nur schauen, wie ich aus dem bin file ein entsprechendes > S19 zusammen bastel. srec bzw. srec_cat kennt sehr viele Optionen, siehe z.B. hier: https://manpages.ubuntu.com/manpages/bionic/man1/srec_cat.1.html https://manpages.ubuntu.com/manpages/bionic/man1/srec_examples.1.html Damit sollte es möglich sein die passende Datei zu erzeugen. Wenn es nicht in einem Rutsch gelingt könnte man auch die einzelnen Pages getrennt in S19 Dateien umwandeln und aus den Teilen das Resultat erzeugen (S19 ist ja nur ASCII Text, das geht mit jedem Editor).
Yes, der Weg sollte relativ klar sein. Mit etwas Übung bekomme ich das vielleicht auch als batch file hin. Der "010 Editor" kann übrigens S19 ganz einfach importieren und macht daraus einwandfreie bin Files. Nur zurück braucht es wohl srec_cat Aber ein bin in 16k Blöcke zu zerlegen und an die richtigen Positionen zu schieben, sollte damit eine lösbare Aufgabe sein. Freu mich gerade sehr, das meine Kunden ncht 3 Wochen im Regen stehen müssen.
Wo man vielleicht noch aufpassen muss ist der TRIM Wert für den internen Takt. Die stehen am Ende des Flash, je nach Anwendungsfall sollte man den Factory-Wert erhalten.
Ich muss das leider doch noch mal ausgraben, weil es dann doch noch ein
Problem gibt.
Ich hab heute mal auf meinem Linux Rechner das USBDM Paket runter
geladen, durchkompiliert und installiert, damit ich eine zweite, mehr
aktuelle Software als die Win XP Umgebung habe.
Dann hab ich das gleiche wie auf dem XP Rechner gemacht
Memory Dump paged mit PPAGE = 0x78 (aus dem Datenblatt)
08000 - 0BFFF
18000 - 1BFFF
28000 - 2BFFF
38000 - 3BFFF
48000 - 4BFFF
58000 - 5BFFF
Das sollten dann all 6 Pages mit je 16k sein
Das wird so auch ohne Probleme ausgelesen.
Mit srec_info bekomme ich zu dem s19 File die folgende Info:
address record
Data: 009900 - 00BBFF
018000 - 01BFFF
028000 - 02BFFF
038000 - 03BFFF
048000 - 04BFFF
058000 - 05BFFF
Der abweichende erste Eintrag ist in so fern nachvollziehbar, da die
Page 0 nur 1960 Bytes hat.
Wenn ich jetzt unter Linux mit dem HCS08 Programmer ein Verify mache,
bekomme ich einen Error.
Den bekomme ich unter WinXP zwar nicht, aber ich vermute, das dort ein
Fehler vorliegt. Dem Linux Rechner vertraue ich an dieser Stelle mehr.
Tscha... leider noch noch nicht am Ziel.
Andere Frage: wie könnte man denn das EEPROM neu schreiben?
:
Bearbeitet durch User
Ralf G. schrieb: > > Der abweichende erste Eintrag ist in so fern nachvollziehbar, da die > Page 0 nur 1960 Bytes hat. Weil die Option "Keep Empty SRECs" nicht gesetzt ist? Ansonsten sollte genau die gelesene Anzahl Bytes drinnen sein. Und damit wird u.U. auch der Vergleich unsicher: "Keep Empty SRECs" läßt soweit ich mich erinnere längere 0xFF Folgen weg. Wenn man aber ohne Optionen mit srec_cat eine Umwandlung in eine Binärdatei macht füllt srec_cat leere Bereich mit 0x00. > Andere Frage: wie könnte man denn das EEPROM neu schreiben? Per BDM geht es auf jeden Fall, ich weiss nur nicht auf Anhieb ob das USBDM kann. Theoretisch könnte man die einzelnen Bytes der EEPROM durch einzelne Zugriffe auf dei Register schreiben aber das ist bei mehr als ein paar Bytes wenig sinnvoll.
Danke Dieter, ich habs auch mit "Keep Empty SRECs" probiert. Stimmt, dann sagt srec_info genau das, was ich auch gelesen habe, aber trotzdem schlägt das folgende verify mit dem HCS08 Flash Programmer fehl. Hab schon versucht mit width 1 und width 2 zu lesen, aber das Ergebnis ist das selbe.
Mir ist momentan nicht klar was schief geht: Du hast ganz am Anfang geschrieben dass es jetzt beim Lesen funktioniert und ein Verify passt. Jetzt geht aber das Verify bei einem selbst kompilierten USBDM nicht mehr. Wenn ich das so richtig verstanden habe dann würde ich bei der Version bleiben bei der es funktionert hat. Wo sind denn die Unterschiede beim Verify? Wenn man rausfinden will was nicht stimmt muss man sich das Ganze im Detail ansehen. Ich hatte die Sourcen von USBDM ja schon erwähnt. Die sind nicht so kompliziert und das BDM Protokoll ist dokumentiert (ich habe damit mal für eine Spezialanwendung BDM für einen HCS08 auf einem STM32 umgesetzt, das war in ein paar Stunden erledigt).
....ich befürchte die Zeit hab ich momentan einfach nicht, mich da in der Tiefe einzuarbeiten. Tatsache ist: auf dem WinXP liest er mit Memory Dump ohne Fehlermeldung aus und ein Verify sagt es wäre korrekt. Gestern habe ich aber mal einen Prozessor programmiert und ein verify gemacht, und das schlägt fehl. Es scheint, das es einen Unterschied gibt, wie das S19 File (paged) gelesen wird, und wie geschrieben. Irgendwie kann man das wohl auch debuggen, aber ich muss erst mal lesen wie das geht. Auf dem Linux Rechner mit frisch kompilierten USBDM Paket kann ich ebenso ohne Fehlermeldung lesen, aber dann schlägt selbt mit dem Prozessor den ich just gelesen hab das verify fehl. Das im Linux Paket enthaltene und frisch kompilierte "usbdm-flash-image-test" Tool crasht selbst ohne Angabe einer Datei. Die Firmware des Programmers habe ich doppelt und dreifach geprüft, und die muss ok sein. So langsam hab ich das Gefühl, das das ganze USBDM Zeug mit ner ziemlich heissen Nadel gestrickt ist. Mit dem XProg-M hatte ich NIE auch nur ein Problem. Weder mit Flash noch mit Eeprom. Schiet.... Hier im Forum hat joergwolfram mal einen Universalprogrammer bereit gestellt, der auch HCs08 unterstützt... aber bis ich dafür die Platinen hab, und alles aufgebaut habe, ist vermutlich schon die Lieferung aus China da. Ich kann gar nicht sagen, wir mir das gerade auf den Keks geht. So was passiert immer zum unpassendsten Zeitpunkt.
:
Bearbeitet durch User
Wenn Du die Datei, die Du programmierst, und das was Du beim Verify ausliest, hier reinstellt kann ich schauen ob mir was auffällt. Wenn die Firmware "geheim" sein sollte könntest Du das Ganze auch mit irgendeiner Demo-Firmware machen, das sollte ja sie selben Probleme zeigen. Dazu dann vielleicht noch ein Screenshot der Einstellungen von USBDM beim Programmieren.
Das ist ein mehr als nettes Angebot! Ich hab gerade mal auf dem Linux Rechner sowohl Flash als auch EEprom ausgelesen. Die Settings hab ich mit dazu gepackt. Wenn ich damit dann ein Verify auf dem Linux Rechner versuche, schlägt das nach ein paar kb fehl.
Zum Vergleich brauche ich noch die Datei, die Du mit USBDM programmiert hast. In "Export.zip" ist nur "EEProm_read_linux.s19" und "Flash_paged_read_linux.s19", das sind wohl die Daten, die Du gelesen hast.
Die Flash_paged_linux.s19 ist die, die ich auch zum Programmieren genommen habe. Im Prinzip will ich einfach nur das Device clonen. So hab ich es schon etliche mal mit dem XPRog gemacht: einfach Flash schreiben, Eeprom schreiben. Fertig. Alles über das BDM Interface. Dauert sonst vllt 5 min. Ich könnte dir zum Vergleich noch die bin Datei des XProg hier einstellen.
:
Bearbeitet durch User
Ralf G. schrieb: > Die Flash_paged_linux.s19 ist die, die ich auch zum Programmieren > genommen habe. Wenn ich Dich richtig verstanden habe funktioniert das Verify nicht, d.h. für mich dass die Datei, die Du programmiert hast nicht mit dem übereinstimmt, das ausgelesen wurde. Den EEPROM berücksichtige ich momentan noch nicht, nur den Flash. Damit ich den Fehler beim Verify nachvollziehen kann brauche ich die Datei, die Du programmiert hast und die Datei, die Du zurückgelesen hast. Bisher habe ich nur eine Datei vom Flash (Flash_paged_read_linux.s19), die kann ich noch nicht vergleichen. Du kannst gerne noch die XPROG Datei reinstellen wenn ich damit dann die Referenz zum Vergleich habe.
T'schuldigung... Missverständniss! Anbei noch mal das zip File, diesmal noch mit dem read_back File und dem bin, das ich sonst mit dem XProg verwende.
Nur mal auf die schnelle geprüft: ich sehe lediglich zwei Bytes Unterschied zwischen Flash_paged_read_linux.s19 und Flash_paged_readback_linux.s19. Das schaut für mich spontan nach den weiter oben erwähnten TRIM Werten aus. Ich schaue später nochmal genauer rein.
Wenn man die Pages aus "Flash_paged_readback_linux.s19" bzw. "Flash_paged_read_linux.s19" herausholt und aneinanderhängt dann bekommt man das was der XPROG Datei entspricht. Also z.B. die "s19" Dateien mit srec_cat ohne Option direkt in eine BIN Datei umwandeln, dann sind die Pages hier:
1 | 0x08000 0x0BFFF |
2 | 0x18000 0x1BFFF |
3 | 0x28000 0x2BFFF |
4 | 0x38000 0x3BFFF |
5 | 0x48000 0x4BFFF |
6 | 0x58000 0x5BFFF |
Das ist jetzt keine Überraschung weil das ja dem entspricht wie USBDM die Pages behandelt. Die erste Page ist leer, auch bei der Flash_used_with_Xprog.bin Datei (da sind nur 0xFF bzw. 0x83 Bytes, los geht es bei Offset 0x4000). Ich sehe dann auch viele Unterschiede zwischen "Flash_used_with_Xprog.bin" und "Flash_paged_readback_linux.s19" bzw. "Flash_paged_read_linux.s19", das sieht für mich aber nach unterschiedlichen Software-Versionen aus (es besteht eine gewisse Ähnlichkeit, der eigentliche Code ist aber unterschiedlich lang). Zwischen "Flash_paged_readback_linux.s19" bzw. "Flash_paged_read_linux.s19" gibt es wie schon geschrieben zwei Bytes Unterschied in Page 3, das sind die TRIM Werte (0xFFAE bzw. 0xFFAF beim MC9S08DZ).
Wenn Du die "Flash_used_with_Xprog.bin" mit srec_cat in eine S19 Datei für USBDM umwandeln willst geht das übrigens mit dieser Windows Batch Datei (als Linux Shell Skript entsprechend):
1 | @echo off |
2 | srec_cat.exe %1 -Binary -crop 0x00000 0x04000 -offset 0x08000 ^ |
3 | %1 -Binary -crop 0x04000 0x08000 -offset 0x14000 ^ |
4 | %1 -Binary -crop 0x08000 0x0C000 -offset 0x20000 ^ |
5 | %1 -Binary -crop 0x0C000 0x10000 -offset 0x2C000 ^ |
6 | %1 -Binary -crop 0x10000 0x14000 -offset 0x38000 ^ |
7 | %1 -Binary -crop 0x14000 0x18000 -offset 0x44000 ^ |
8 | -Output %2 -Motorola |
Aufruf mit "sconv.bat Flash_used_with_Xprog.bin Flash_used_with_Xprog.s19" wenn die Batch Datei "sconv.bat" heisst. Das ist nur ein schnell zusammengebautes Beispiel für sech Pages. "^" ist für das Aufsplitten auf mehrere Zeilen in einer Batch Datei. Die Summe aus dem "-offset" und dem ersten "-crop" Parameter sind dann wieder die bekannten Adressen:
1 | 0x08000 |
2 | 0x18000 |
3 | 0x28000 |
4 | 0x38000 |
5 | 0x48000 |
6 | 0x58000 |
Beitrag #7258322 wurde von einem Moderator gelöscht.
Wahnsinn, was du mal eben in zwei Stunden zu Stande bringst. Ich werde morgen mal einfach versuchen aus der XProg Datei ein s19 zu machen und das zu schreiben. Mal sehen was passiert. Ich hab mal versucht infos oder Programme zu finden, die auch das Eeprom schreiben. Aber da war gar nichts. Oder schreibt das etwa (einfach) auch der Flash Programmer????
....kurz noch zu den Unterschieden, die du oben genannt hast: ich vermute, das das HCS08 Flash-Programm gar nicht geschrieben hat. Ich hatte das auf dem WinXP Rechner gemacht, und das lief auch ohne Fehlermeldung durch, aber am Verhalten des Devices hatte sich nichts geändert. Ich probier jetzt mal das s19 file aus dem bin zu erstellen, und das dann mit dem Linux Rechner zu schreiben.
Gesagt - getan: Zunächst aus dem bin File mit dem Batch ein s19 generiert Auf dem Linux-Rechner: das s19 File geschrieben (Programmierung lief durch ohne Fehlermeldung) Beim Verify gab es dann eine Fehlermeldung. Als Einstellung verwende ich "selective erase", weil bei "no erase" gibt es eine entsprechende Fehlermeldung, das die Bereiche nicht leer seien. Trotzdem einfach mal die Funktion des Gerätes getestet, und es verhält sich immer noch wie zuvor. Es scheint, das auch hier nicht geschrieben wurde. Ich hab dann einfach wieder ausgelesen, was im Flash steht, den ich ja gerade geschrieben hatte, aber da scheint was völlig anderes zu stehen, wenn ich das richtig sehe. Ich hab leiner keinen Hex Editor, der s19 schön darstellt....
:
Bearbeitet durch User
Angehängte Dateien:
-
USBDM_Program_MC9S08LH64.PNG
6,9 KB
Ich sehe ehrlich gesagt nicht wo das Problem sein sollte. Die Dateien aus dem bin.zip (Flash_CH12_XPROG_readback.s19 und Flash_CH12_XPROG.s19) unterscheiden sich nur in zwei Bytes, das sind die bereits erwähnten TRIM Werte. Das kann man einfach prüfen: die S19 Dateien mit srec_cat in Binär Dateien umwandeln und dann die Binärdateien vergleichen, das geht sogar mit den Windows-Kommandozeilentools (FC mit Option "/b"). Dann kommt folgendes raus
1 | Vergleichen der Dateien Flash_CH12_XPROG.bin und FLASH_CH12_XPROG_READBACK.BIN |
2 | 0003BFAE: FF 01 |
3 | 0003BFAF: FF B5 |
Das sind die TRIM Werte in Page 3 (0xFFAE bzw. 0xFFAF beim MC9S08DZ) Ich habe hier auch kurz mit einem MC9S08LH64 das Flashen mit USBM probiert, das funktioniert wie erwartet (eine ältere Version USBDM_4_12_1_262_Win von SourceForge). Einstellungen siehe Bild, das ist im Prinzip der Default.
Ich höre was du sagst, aber es ist mir total schleierhaft, was hier bei mir abläuft. Besonders auch weil das verify immer einen Fehler berichtet. I hohl mal etwas weiter aus: Das "defekte" Gerät verhält sich seltsam. Das kenne ich schon, weil der original Entwickler hat bei der Entwicklung was falsch gemacht. Bislang hab ich bei den defekten Geräten das Flash-Image von einem intakten via XProg aufgespielt und dann war wieder alles ok. Also (so dachte ich) kann es nichts mit dem EEprom zu tun haben, weil den hab ich immer so gelassen. Vielleicht versuche ich einfach mal ein Mass-Erase?
Ralf G. schrieb: > Ich höre was du sagst, aber es ist mir total schleierhaft, was hier bei > mir abläuft. Besonders auch weil das verify immer einen Fehler > berichtet. Das würde ich auf die TRIM Werte zurückführen weil diese in der S19 Datei stehen aber normalerweise nicht im Flash beim Programmieren überschrieben werden. Das Zurücklesen zeigt ja dass der Rest passt. > > Also (so dachte ich) kann es nichts mit dem EEprom zu tun haben, weil > den hab ich immer so gelassen. Bisher wurde ja nur der Flash kopiert und nicht der EEPROM, vielleicht liegt es ja daran? Zu dem EEPROM Programmieren: das sollte mit USBDM gehen. Die Details stehen in der Datei "hcs08_devices.xml" im Verzeichnis "DeviceData", dort nach MC9S08DZ96 suchen. Bei meiner USBDM Version steht da dann für den EEPROM als Bereich 0x003C00..0x003FFF und 0x013C00..0x013FFF. Ich würde davon ausgehen dass beim Flashen mit dem UsbdmFlashProgrammer die Daten in diesem Bereich in den EEPROM programmiert werden. Also mit srec_cat den EEPROM Inhalt in den entsprechende Bereich der S19 Datei bringen und dann programmieren. Ausprobieren kann ich es nicht weil ich keinen HCS08 mit EEPROM hier habe. > Vielleicht versuche ich einfach mal ein Mass-Erase? Du hast das Gerät zum Testen, kaputt gehen sollte dabei ja nichts. Eventuell muss man danach die TRIM Werte zurückschreiben.
So.... endlich mal ein Zeichen von Erfolg! Ich hab ein Mass-Erase gemacht und danach die s19 Version des bin Files geschrieben. Und siehe da: auf einmal verhält sich das Teil wieder so wie es soll! Der Laie staunt und der Fachmann wundert sich. Für das EEprom muss ich noch was lesen.... das ist beim DZ96 nicht paged, aber ich vermute es wird ehn nur der erste Bereich verwendet. Wie bekomme ich denn den richtigen Trim Wert raus... oder warum wird der überhaupt verändert?
:
Bearbeitet durch User
Ralf G. schrieb: > > Für das EEprom muss ich noch was lesen.... das ist beim DZ96 nicht > paged, aber ich vermute es wird ehn nur der erste Bereich verwendet. Im Datenblatt des MC9S08DZ steht dass man zwei EEPROM Hälften umschalten kann, USBDM scheint das über Pages zu realisieren. > Wie bekomme ich denn den richtigen Trim Wert raus... oder warum wird der > überhaupt verändert? Man kann bei USBDM einstellen ob es die TRIM Werte verändert. Die Factory Werte stehen im Flash, ich weiss nicht ob ein Mass-Erase diese Werte löscht.
Aus dem Datenblatt: 4.6.10 EEPROM Mapping Only half of the EEPROM is in the memory map. The EPGSEL bit in FCNFG register selects which half of the array can be accessed in foreground while the other half can not be accessed in background. There are two mapping mode options that can be selected to configure the 8-byte EEPROM sectors: 4-byte mode and 8-byte mode. Each mode is selected by the EPGMOD bit in the FOPT register. In 4-byte sector mode (EPGMOD = 0), each 8-byte sector splits four bytes on foreground and four bytes on background but on the same addresses. The EPGSEL bit selects which four bytes can be accessed. During a sector erase, the entire 8-byte sector (four bytes in foreground and four bytes in background) is erased. In 8-byte sector mode (EPGMOD = 1), each entire 8-byte sector is in a single page. The EPGSEL bit selects which sectors are on background. During a sector erase, the entire 8-byte sector in foreground is erased. Also möchte ich mit EPGSEL (Bit 6 in Register 0x1823) die jeweilige Seite auswählen, und mit EPGMOD (Bit 5 in Register 0x1821) den 8bit / Single Page mode auswählen Also versuche ich den Memory Dumper mit (1821,32) (1823,64) zu intialisieren, um die zweite Seite des EEprom zu lesen. Das gibt leider ein "Illegal Parameter" EDIT: Geht schon... es darf nur kein Leerzeichen zwischen den beiden Klammern sein. Aber zunächst bin ich erst mal froh, das ich mit deiner Hilfe überhaupt so weit gekommen bin.!!! Vielen vielen Dank!!!
:
Bearbeitet durch User
Wenn es jetzt mit den "Initialization" Parametern funktioniert: Kannst Du damit den kompletten EEPROM auslesen? Das sollte auf jeden Fall funktionieren. Zum Programmieren des EEPROM siehe weiter oben: das müsste man ausprobieren.
Ja, das EEprom auslesen funktioniert prima. Muss man aber eben in zwei Schritten machen. In meinem Fall enthält EEprom Page 0 Daten, Page 1 ist leer.
....wenn man mal ne Nacht drüber geschlafen hat und denn Tunnelblick mal kurz bei Seite lässt: wenn die Adressen beim Initialize in Hex übergeben werden (0x1821 und 0x1823), sollte man vielleicht auch die Werte in Hex (0x20 und 0x40) übergeben? Werde ich heute auch noch mal prüfen.
Ralf G. schrieb: > ....wenn man mal ne Nacht drüber geschlafen hat und denn Tunnelblick mal > kurz bei Seite lässt: wenn die Adressen beim Initialize in Hex übergeben > werden (0x1821 und 0x1823), sollte man vielleicht auch die Werte in Hex > (0x20 und 0x40) übergeben? Werde ich heute auch noch mal prüfen. Die Zahlen bei der "Initialization" sind in HEX. Übrigens kann man bei USBDM eine Menge automatisieren, siehe UsbdmScript mit TCL.
Das mit den Scripten schau ich mir auf jeden Fall an (sobald ich wieder etwas Zeit habe). Und wegen Trim Informationen: Wie es scheint, kann man die nicht so ohne weiteres mit dem USBDM schreiben. Vielleicht ist das der Grund, warum ich immer verify errors bekomme. https://community.nxp.com/t5/OSBDM-and-TBDML/USBDM-CF-3-1-UsbdmScript-TCL-Interpreter-commands/m-p/930377
Ralf G. schrieb: > > Und wegen Trim Informationen: Wie es scheint, kann man die nicht so ohne > weiteres mit dem USBDM schreiben. Vielleicht ist das der Grund, warum > ich immer verify errors bekomme. > > https://community.nxp.com/t5/OSBDM-and-TBDML/USBDM-CF-3-1-UsbdmScript-TCL-Interpreter-commands/m-p/930377 Dort es geht es meiner Meinung nach nur darum dass USBDM die TRIM Daten nicht aus der IDE bekommt. Schreiben kann USBDM die schon, bei meinem MC9S08LH64 geht es.
... ich befürchte, das wird für mich noch eine Menge Arbeit und Informationssuche, bis ich das hier vollumfänglich verstanden habe. Fakt ist: Gestern hab ich noch mal so ein defektes Teil zu retten versucht. Also erst ein mal den gesamten Flash gelesen
1 | 0x08000 0x0BFFF |
2 | 0x18000 0x1BFFF |
3 | 0x28000 0x2BFFF |
4 | 0x38000 0x3BFFF |
5 | 0x48000 0x4BFFF |
6 | 0x58000 0x5BFFF |
´ und Page 0 vom EEProm
1 | 0x3C00 0x3CFF |
Ich hatte mit deinem Skript aus dem funktionierenden bin File ja ein s19 gemacht. Das hab ich dann in den Flash programmiert. Als Erase-Strategie hab ich mal "Target Default" probiert, aber das war dann ein "Mass Erase". Nach einem Mass Erase ist aber nicht nur der Flash sondern auch das EEProm leer. Naja, dachte ich, ich hab ja alle Daten. Nachdem ich das Flash geschrieben habe (natürlich mit dem immer währenden Verify Error), funktioniert das Device wieder, hat aber noch keine Settings. Wenn ich dann das EEprom S19 wieder programmiere, funktioniert das zwar ohne Verify Error (!), aber das Gerät funktioniert nicht mehr. Es scheint, das der nicht in den EEprom Speicher, sondern irgendwo in den Flash schreibt. Naja.... das usbdm Tool heisst ja auch "Flash Programmer" ... Aber: XProg kann das ja auch. Also muss es irgendwie gehen. Irgendwas mache ich noch falsch. Inzwischen sind zwei Ersatz-Prozessoren für mein XProg auch China angekommen (ATMega64A) und ich hab den defekten natürlich sofort getauscht, aber Essig... funktioniert nicht. Keine Reaktion vom neuen ATMega... auch der zweite Chip nicht.... Also bin ich bis auf Weiteres auf usbdm angewiesen. Was für eine Katastrophe. VG Ralf
:
Bearbeitet durch User
Zu dem EEPROM Programmieren mit USBDM kann ich wenig sagen weil ich wie schon geschrieben keinen HCS08 mit EEPROM hier habe. Ich habe Dir eine PM geschrieben.
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.