Forum: Compiler & IDEs Lesen / Schreiben 9S08DZxx


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Ralf G. (dougie)


Angehängte Dateien:

Lesenswert?

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

: Bearbeitet durch User
von Ralf G. (dougie)


Angehängte Dateien:

Lesenswert?

...Topic kann geschlossen werden, weil der Benutzer zu dämlich ist, oder 
0204 Widerstände nicht mehr mit dem Auge erkennt.

von ... (Gast)


Lesenswert?

Die widerlichen Details waeren schon interessant.
So einen (Spezial-)BDM habe ich auch und noch nie benutzt.

von Ralf G. (dougie)


Lesenswert?

...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.

von Dieter (Gast)


Lesenswert?

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.

von Ralf G. (dougie)


Lesenswert?

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
von Dieter (Gast)


Lesenswert?

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

von Ralf G. (dougie)


Lesenswert?

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
von Dieter (Gast)


Lesenswert?

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.

von Ralf G. (dougie)


Angehängte Dateien:

Lesenswert?

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
von Ralf G. (dougie)


Lesenswert?

....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

von Dieter (Gast)


Lesenswert?

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.

von Ralf G. (dougie)


Lesenswert?

… je nachdem wie viel ich da lesen und lernen muss, kann ich auch die 
drei Wochen warten :/

von Dieter (Gast)


Angehängte Dateien:

Lesenswert?

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.

von Ralf G. (dougie)


Lesenswert?

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
von Dieter (Gast)


Lesenswert?

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).

von Ralf G. (dougie)


Lesenswert?

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.

von Dieter (Gast)


Lesenswert?

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.

von Ralf G. (dougie)


Lesenswert?

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
von Dieter (Gast)


Lesenswert?

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.

von Ralf G. (dougie)


Lesenswert?

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.

von Dieter (Gast)


Lesenswert?

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).

von Ralf G. (dougie)


Lesenswert?

....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
von Dieter (Gast)


Lesenswert?

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.

von Ralf G. (dougie)


Angehängte Dateien:

Lesenswert?

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.

von Dieter (Gast)


Lesenswert?

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.

von Ralf G. (dougie)


Lesenswert?

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
von Dieter (Gast)


Lesenswert?

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.

von Ralf G. (dougie)


Angehängte Dateien:

Lesenswert?

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.

von Dieter (Gast)


Lesenswert?

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.

von Ralf G. (dougie)


Lesenswert?

Vielen lieben Dank für all deine Mühe und Alteilnahme!!

von Dieter (Gast)


Lesenswert?

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).

von Dieter (Gast)


Lesenswert?

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.
von Ralf G. (dougie)


Lesenswert?

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????

von Ralf G. (dougie)


Lesenswert?

....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.

von Ralf G. (dougie)


Angehängte Dateien:

Lesenswert?

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
von Dieter (Gast)


Angehängte Dateien:

Lesenswert?

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.

von Ralf G. (dougie)


Lesenswert?

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?

von Dieter (Gast)


Lesenswert?

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.

von Ralf G. (dougie)


Lesenswert?

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
von Dieter (Gast)


Lesenswert?

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.

von Ralf G. (dougie)


Lesenswert?

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
von Dieter (Gast)


Lesenswert?

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.

von Ralf G. (dougie)


Lesenswert?

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.

von Ralf G. (dougie)


Lesenswert?

....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.

von Dieter (Gast)


Lesenswert?

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.

von Ralf G. (dougie)


Lesenswert?

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

von Dieter (Gast)


Lesenswert?

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.

von Ralf G. (dougie)


Lesenswert?

... 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
von Dieter (Gast)


Lesenswert?

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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.