Ich habe hier zwei Fahrzeugmodule (Rückfahrkamera) aus dem Baujahr
2009-2012. Bei einem wird der Lenkwinkel über CAN-Bus, bei dem anderen
über ein analoges Signal (vermutlich PWM) eingespeist. Das Modul mit dem
analogen Lenkwinkelsignal funktioniert grundsätzlich auch anstelle dem
mit CAN-Lenkwinkel, jedoch werden die Linien nicht angezeigt. Von der
Platine und den Komponenten her sind beide gleich, also ist es nur eine
Frage der Software.
In beiden Modulen werkelt ein MC9S12 Mikrocontroller, wie man ihn häufig
in KFZ-Modulen verschiedenster Art findet. Dieser gehört zur
HCS12-Familie und verfügt über einen BDM-Anschluß zum debuggen und
programmieren. Den Debug-Header konnte ich schnell identifizieren. Dann
habe ich einen (China) USBDM an diesen Header verbunden versucht und
mittels der USBDM-Software von Sourceforge
https://sourceforge.net/p/usbdm/wiki/Home/ irgendwas sinnvolles zu tun,
jedoch wird jeder Connect-Versuch mit einer Fehlermeldung quittiert.
Soweit ich die Signale gemessen habe sind MODA und MODB mit Widerständen
auf GND gezogen und damit "0", was einem normalen Betriebsmodus
entspricht.
Wer kennt sich mit sowas aus und kann mit etwas "Starthilfe" geben wie
ich an die Register, den RAM, Flash und EEPROM herankomme?
René F. schrieb:> Der Controller wird garantiert gegen Auslesen geschützt sein, je nach> Programmierung kann der Readout auch mit einem Passwort versehen sein.
Davon ging ich auch aus, aber dem ist wohl nicht so.
Inzwischen habe ich es geschafft. Und zwar verwende ich diesen
USBDM-Clone (China-Ware). Das Pinout habe ich mal angefügt, weil man da
leicht in die Irre geführt wird. Oft wird nur das Pinout auf dem Board
angegeben, das am Stecker ist natürlich spiegelverkehrt ;-)
Dann habe ich USBDM installiert und dort gibt es eine ganze Reihe von
Tools, u.a. den "USBDM Memory Dump". Dort habe ich zunächst den
Prozessortyp eingestellt und die USBDM Geschwindigkeit auf 12MHz. Dann
den auszulesenden Speicherbereich (hier war ich großzügig und habe von
0x0000 bis 0xFFFF mal alles genommen, ist ja nur eine 16-Bit CPU drin).
Das Tool speichert den readout im Motorola S12-Format, welches man z.B.
mit HxD in eine lineare Binärdatei wandeln kann. Habe von beiden Modulen
mal den Readout angehangen. Beim 8M5T habe ich zweimal ausgelesen und es
gibt erstaunlich viele Unterschiede. Hier hätte ich jetzt nur welche in
den RAM-Bereichen erwartet.
Für das 9M5T habe ich auch mal die Original-Firmware-Updatedatei
angefügt, mit der das Modul aktualisiert wurde.
Jetzt versuche ich aus dem ganzen mal schlau zu werden (natürlich sehr
gern mit Eurer Hilfe! :-) und letztlich einen Weg zu finden die 9M2J
Firmware vom 9M5T-Modul auf das 8M5T-Modul zu kopieren.
Die VBF-Datei dient einem CAN-basierenden Updater zum aktualisieren
eines Moduls. Das 8M5T ist für ein anderes Fahrzeugmodell gedacht und
ich kann ihm die 9M2J-Firmware nicht einfach so unterschieben. Die VBFs
enthalten in der Regel einen secondary-bootloader, welcher in den RAM
des µC im Modul eingebracht und ausgeführt wird und dieser dann den Rest
des Updates (Flash löschen, Daten vom CAN lesen, Flash beschreiben,
usw.) durchführt. In dem VBF-Header (im Binären Teil) wird in der Regel
auch eine Startadresse angegeben. Ich vermute aber stark das dies der
Teil ab 0x4000 ist. Dort ist im Moduldump kein Inhalt zu sehen, was
dafür spricht das dieser Bereich speziell für einen Updater (2nd
Bootloader) freigehalten wurde.
Wenn die Memory-Map die ich aus dem Datenblatt vom MC9S12DG habe stimmt,
dann beginnt ab 0x4000 der 16KB große Flash-Speicher (EEPROM) vom Chip.
Eine Idee wäre nun den MC9S12 auf dem 8M5T-Board zu löschen (Mass erase)
und mit dem Dump vom 9M5T-Board zu beschreiben... danach sollte sich
dann das Modul am CAN-Bus wie ein 9M5T "zeigen" und nochmal ein
"normales" Update annehmen.
Dieter schrieb:> Du hast aber schon verstanden dass der MC9S12 Pages verwendet?
Ja, hab ich gelesen, aber ich dachte die werden nur für externe
Ressourcen genutzt?
Olli Z. schrieb:>> Ja, hab ich gelesen, aber ich dachte die werden nur für externe> Ressourcen genutzt?
Im Datenblatt steht doch alles, außerdem beschreibt der Beitrag in dem
Link wie man vorgeht (diesen Betrag zu finden ist nicht schwer).
Und wenn man dann noch den EEPROM aktiviert bevor man ihn auslesen
möchte werden vermutlich Daten in Bereich des EEPROM auftauchen (auch
das wird im Beitrag des Links so gemacht).
XPROG wurde hier ja schon erwähnt, das ist für Leute die sich nicht
näher mit den Details beschäftigen wollen besser geeignet als USBDM...
Laut VBF wird zunächst der erste Block (0x140) an Adresse 0x4000 geladen
und ausgeführt. Was man darin findet scheint aber kein HCS12 opcode zu
sein, sieht mir eher aus wie eine Vektortabelle:
Dieter schrieb:> XPROG wurde hier ja schon erwähnt, das ist für Leute die sich nicht> näher mit den Details beschäftigen wollen besser geeignet als USBDM...
Eigentlich will ich mich mit Details beschäftigen, sonst hätte ich hier
kaum gefragt. Das aber nur nebenbei.
Um eine Verifikation zu haben habe ich mir XPROG mal angesehen. Vor 2-3
Jahren habe ich mir mal so ein China-Teil bestellt aber nie was mit
gemacht, also Premiere.
Naja und so "straight-forward" war es dann nun auch nicht das Ding ans
laufen zu bekommen. Zuerst musste ich meinen USBASP updaten, mit einem
UNO als ISP-Programmer. Dann den USB-Chip vom XPROG neu flashen und eine
"spezielle" Version von XPROG 5.51 installieren (alles aus dieser
Anleitung entnommen:
https://www.e90post.com/forums/showthread.php?t=1838104). Am Ende konnte
ich damit EEPROM und FLASH auslesen. Jetzt muss ich das erstmal
analysieren. Ich habe zunächst mal die "unprotected" Variante vom
"MC9S12_FLASH" und "MC9S12_EEPROM" gewählt. Darin beschrieben ist auch
meine Variante mit dem MC9S12DG128 in der QFP80. Das ganze lies sich
ohne anlegen der Stromversorgung am Modul, rein durch +5V vom XPROG
bewerkstelligen. Die Dumps beider Module habe ich mal beigefügt.
Eine erste Stichprobe mit dem 9M5T ergab, das ich nur einen Teil der im
VBF steckenden Software im MC9S12 Flash finde:
1
VBF-START LEN DUMP-START
2
0x00004000 (0x140) 0x00068000
3
0x00004A00 (0x171E) 0x00068A00
4
0x00007200 (0xE00) 0x0006B200
5
0x0000C000 (0x3A) 0x00078000
6
0x0000C080 (0x9BA) 0x00078080
7
0x00388000 (0x3FFA) -!-
8
0x00398000 (0xC46) -!-
9
0x003C8000 (0xB10) -!-
10
0x003D8000 (0x33EE) -!-
Das was XPROG da ausgelesen hat finde ich auch 1:1 in meinem USBDM-Dump
wieder. Einzig das XPROG die unprogrammierten Bereiche im Flash als 0xFF
und USBDM diese als 0x00 ausgibt.
Den Inhalt des EEPROMs finde ich z.B. garnicht im Update-File, was aber
auch so gewollt sein kann.
Das Flash-Protection-Byte 0x7BF0F steht auf 0xFE und zeigt somit einen
ungeschützten Flash an (wenn ich es richtig interpretiert hab):
Block 0 und Block 1 Protection-Bytes 0x7BF0C und 0x7BF0D sind jedoch
0xFF. Könnte das der Grund sein warum die Blöcke im Dump leer sind? Ich
versuche es dann doch mal mit einem Secured-Readout. Der ist etwas
komplexer weil auch CLK verbunden werden muss. Ich nehme an der XPROG
macht hier ein paar "Glitches".
Der XPROG Dump passt doch recht gut zu der VBF Datei: Im XPROG Dump sind
die 16 KByte Pages 0x38 bis 0x3F. Und in der VBF Datei die Pages 0x38,
0x39, 0x3C
und 0x3D (die Page steht ja deutlich sichtbar als MSB der Adresse) sowie
die Page 0x3E (Adresse 0x4000 bis 0x7FFF, siehe Datenblatt) sowie Page
0x3F (Adresse 0xC000 bis 0xFFFF, siehe Datenblatt).
Nur der Inhalt des Dumps passt nicht überall exakt zur VBF Datei weil
die Firmware Version der VBF Datei vermutlich nicht die selbe wie im
Steuergerät ist.
Ich versuche mich mal mit nem Faktencheck: Der MC9S12DG128 ist eine
16-Bit HCS12 CPU mit M68HC11 Instruction-Set, 128K Flash (131.072,
0x20000), 2K EEPROM (2048, 0x800) und 8K RAM (8192, 0x2000)
Die Memory-Map nach dem Reset ist so wie der Datenblatt-Auszug zeigt,
also aufgrund des begrenzten Adressraumes der CPU (16-Bit = 0x0000 -
0xFFFF) wird zunächst "von allem etwas" durch den MMC in den direkt
adressierbaren Bereich der CPU gemapped.
---------------------------------
Im Bereich 0x0000-0x03FF liegt der 1K (1024, 0x400) große
"Register-Space" der verschiedenste Einstellparameter und Zugang zu den
I/O-Bausteinen des Chips enthält.
Dieser überlagert zum Teil das 2K (0x800, 2048) große Adressbereich des
EEPROMs (0x0000-0x07FF). D.H. nach dem Reset ist direkt nur ein ca. 1,5K
(0x600, 1536) großer EEPROM-Bereich von 0x0200-0x07FF ansprechbar.
Das gleiche gilt für das 2K große RAM, welches auch ab Adresse 0x0000
bis 0x1FFF liegt. Dieses wird vom EEPROM und vom Register-Space
überlagert, sodass direkt nur ein ca. 6KB (0x1800, 6144) großer Bereich
0x0800-0x1FFF direkt verfügbar ist.
Vom 128K Flash wird ab 0x4000 (bis maximal 0x7FFF) zunächst der
"protected low sector" eingeblendet. Dann folgt ein 16K großes "Fenster"
des Flash im Adressbereich von 0x8000-0xBFFF. Und diesem folgt ab 0xC000
der "flash protected high sector" vom Flash.
Ganz am Ende des Adressbereiches liegt die 256 Byte große Vectortabelle
(0xFF00-0xFFFF).
---------------------------------
Der Flash selbst ist intern in zwei 64K Blöcke unterteilt und jeder
Block in 1024 Zeilen zu je 64 Bytes. Die Löschgröße beträgt 8 Zeilen
(512 Byte). Will man also auch nur ein einziges Byte im Flash ändern,
muss man wenigstens 512 Byte löschen und neu schreiben.
Die 128K des Flash sind nie als ganzes im Adressbereich der CPU
eingeblendet, sondern immer nur max. 16KB davon im mittleren Page-Window
0x8000-0xBFFF. Über das PPAGE-Register im Register-Space wird bestimmt
welcher der acht möglichen 16K Pages aktuell im Adressbereich verfügbar
ist. Nach dem Reset ist das immer die erste Page welche die
Flash-Speicheradresse 0x000000 referenziert. Das PPAGE-Register hält
hierbei den Wert 0x38
Die für die "protected sectors" des Flash in der CPU festgelegten
Speicherbereiche sind fix und zeigen im Flash immer auf dieselbe Stelle,
sind also nicht veränderlich.
---------------------------------
Wenn man also mit USBDM einen Dump von 0x0000 bis 0xFFFF durchführt
erhält man zunächst nur einen der acht 16K Blöcke des Flash. Um mit
USBDM den ganzen Flash zu dumpen muss man also 8 mal den Bereich
0x8000-0xBFFF auslesen und dabei vorher jedesmal das PPAGE auf einen
Wert von 0x38 bis auf 0x3F erhöhen.
Im Adressbereich 0xFF00-0xFF0F der CPU werden die "Flash Protection und
Security Field" Bits gespiegelt. Die 16 Statusregister des Flash werden
in dem CPU-Adressbereich 0x0100-0x010F dargestellt. Interessant ist hier
wohl das FSEC (Flash Security) Register in 0x101. Dieses wird nach dem
Reset aus dem im Flash gespeicherten und in 0xFF0F gespiegelten Register
geladen.
Die Bits 7+6 zeigen mit 0b10xxxxxx an wenn ein Backdoor-Key hinterlegt
ist um die Sicherheit aufzubrechen. Die Bits 1+0 zeigen mit 0bxxxxxx10
an wenn der Flash "entsichert" ist. Mit "Protected" ist dabei gemeint ob
bestimmte Flash-Sektoren beschreibbar oder löschbar sind. Hier ist wohl
für das spätere programmieren wichtig das alle Sektoren beschreibbar
sind.
Mit dem VBF wird also zunächst etwas in den ersten protected low sector
0x3E geschrieben (ab 0x4000, 0x4A00, 0x7200) und anschließend in den
protected high sector 0x3F (ab 0xC000, 0xC080) und dann in die
unprotected Pages 0x38, 0x39, 0x3C und 0x3D.
Was wir nicht sehen ist eine Schreiboperation ins EEPROM. Auch wissen
wir nicht was dem Chip (Flash/EEPROM) als "Grundprogrammierung" bereits
zuteil wurde, da es sich hier ja nur um ein Softwareupdate handelt und
keine initiale Programmierung. Ggf. sind also im EEPROM und Flash noch
Dinge die durch das Update zunächst nicht geändert, zur Gesamtfunktion
aber benötigt werden.
Dieter schrieb:> Der XPROG Dump passt doch recht gut zu der VBF Datei: Im XPROG Dump sind> die 16 KByte Pages 0x38 bis 0x3F. Und in der VBF Datei die Pages 0x38,> 0x39, 0x3C und 0x3D (die Page steht ja deutlich sichtbar als MSB der Adresse)
sowie die Page 0x3E (Adresse 0x4000 bis 0x7FFF, siehe Datenblatt) sowie Page 0x3F
(Adresse 0xC000 bis 0xFFFF, siehe Datenblatt).
Die Software muss das Bank-Paging ja mitmachen bei ihren Sprung und
Adressbefehlen, es ist also vermutlich egal ob die Software "linear"
über die Flash-Blöcke und Pages verteilt ist oder nicht. Die Pages 0x3E
und 0x3F (beides aus Block 0) liegen immer im Adressbereich der CPU.
Diese Pages würden sich dann vermutlich besonders für Library-Funktion
oder (statische)Variablen eignen die jederzeit im Zugriff sein müssen.
Die anderen Pages (0x38, 0x39, 0x3C, 0x3D) dann eher für Programmcode.
Wie könnte man da jetzt zum Disassemblieren ansetzen? Ich würde mit dem
RESET starten. Hier müsste doch wie bei jeder CPU mit Adresse 0x0000
begonnen werden auszuführen? Für gewöhnlich findet man hier die
Interrupt-Vectoren die zum Einsprung führen. Den würde ich jetzt bei
0x8000 erwarten, könnte damit aber auch falsch liegen...
Olli Z. schrieb:>> Wenn man also mit USBDM einen Dump von 0x0000 bis 0xFFFF durchführt> erhält man zunächst nur einen der acht 16K Blöcke des Flash. Um mit> USBDM den ganzen Flash zu dumpen muss man also 8 mal den Bereich> 0x8000-0xBFFF auslesen und dabei vorher jedesmal das PPAGE auf einen> Wert von 0x38 bis auf 0x3F erhöhen.
Warum liesst Du nicht einfach denn Beitrag für den ich den Link gepostet
habe? Da steht die Lösung, die ist zwar für einen etwas anderen Chip
aber es ist doch wirklich nicht schwer die dort beschriebene Lösung um
die paar mehr Pages zu erweitern, die der Chip in Deiner ECU hat.
Olli Z. schrieb:>> Wie könnte man da jetzt zum Disassemblieren ansetzen? Ich würde mit dem> RESET starten. Hier müsste doch wie bei jeder CPU mit Adresse 0x0000> begonnen werden auszuführen?
Wie kommst Du darauf dass jede CPU bei 0x0000 den Reset hat? Ich sag es
nochmal, liess das Datenblatt, da stehen solche Dinge drinnen. Und dann
wunderst Du Dich dass ich davon ausgehe dass Dich die Details nicht
interessieren. Oder erwartest Du dass jemand anderst für Dich das
Datenblatt liesst und Dir die Antworten raussucht?
Dieter schrieb:> Warum liesst Du nicht einfach denn Beitrag für den ich den Link gepostet> habe? Da steht die Lösung, die ist zwar für einen etwas anderen Chip
Das habe ich getan, aber ich lerne noch und muss da erstmal draus schlau
werden. Da mag mir der ein oder andere Denkfehler unterlaufen...
> aber es ist doch wirklich nicht schwer die dort beschriebene Lösung um> die paar mehr Pages zu erweitern, die der Chip in Deiner ECU hat.
Ich habe mir jetzt mal die Firmware VBF besorgt die auch auf dem Modul
geflashed ist und als ZIP angehangen und weil nicht jeder VBF
konvertieren kann auch gleich ein S19 und BIN File davon ins Archiv
gepackt.
Den USBDM Memory Dump habe ich dann so eingestellt wie im VBF die Blöcke
angegeben sind. Einzig mit der WIDTH im USBDM kann ich nichts anfangen,
die habe ich mal auf 1 und 2 probiert, kommt aber dasselbe raus. Hat
hier vielleicht keinen Einfluß?
Nun hätte ich erwartet das mein Dump nahezu gleich mit dem VBF ist, aber
weit gefehlt. Der Dump ist ab 0x388000 sehr unterscheidlich. Komisch
nicht?
Man findet in beiden die gleichen Nummern für Hardware (19H405) und
Software (14F631):
Dieter schrieb:> Wie kommst Du darauf dass jede CPU bei 0x0000 den Reset hat?
Ja, das war dumm von mir. Habe es im Datenblatt gefunden (siehe Bild),
die Vector-Tabelle beginnt ab 0xFF80 und an 0xFFFE sollte der 16 Bit
Vector für POR (Power-On-Reset) liegen, also eine Sprungadresse:
Dort lese ich 0xE0FF (Big-Endian CPU). Das kann aber doch unmöglich eine
valide Sprungadresse sein, da sie ungerade ist und somit ausserhalb vom
SP. Im VBF File ist als Startadresse 0x4000 hinterlegt, das mag aber
evtl. nur für den Update gelten (SBL).
"Lies das Datenblatt" ist aber auch nicht so einfach wie es klingt. Das
sind schließlich mehrere PDFs mit hunderten von Seiten, das muss man
erstmal alles kapieren und im Kopf behalten... aber ich habe wirklich
Stunden darin rumgelesen.
Und nein, ich erwarte nicht das man mir die Stellen im Datenblatt
raussucht, man kann auch einfach so antworten geben ;-)
Olli Z. schrieb:>> Dort lese ich 0xE0FF (Big-Endian CPU). Das kann aber doch unmöglich eine> valide Sprungadresse sein, da sie ungerade ist und somit ausserhalb vom> SP.
Warum kann die Adresse bei dieser CPU nicht ungerade sein? Bei 0xE0FF
liegt der Reset-Code und mit einem Disassembler sieht man schnell dass
es sich um gültigen Code handelt der zu einem Reset-Handler passt.
Auch das findet sich im Datenblatt (es gibt z.B. 1 Byte lange Befehle,
damit ist schnell klar dass es keinen Grund für eine Beschränkung auf
gerade Adressen gibt).
Und nochmal zum Datenblatt: Um die Reset-Adresse zu finden oder die
Pages zu verstehen genügt es ein paar Seiten zu lesen, danach kann man
auch einfach suchen (z.B. nach "reset vector").
Olli Z. schrieb:>> Nun hätte ich erwartet das mein Dump nahezu gleich mit dem VBF ist, aber> weit gefehlt. Der Dump ist ab 0x388000 sehr unterscheidlich. Komisch> nicht?
Ich würde jeweils die komplette 16 kByte Page lesen (also 0x..BFFF als
Ende,
ebenso die komplette Page bei 0x4000 und 0xC000) und schauen was dann
herauskommt. Und als Vergleich den XPROG Dump nehmen weil der vermutlich
passt.
Und man könnte auch noch den EEPROM lesen, mit der Initialisierung und
dem Bereich ab 0x1000.
Dieter schrieb:> Warum kann die Adresse bei dieser CPU nicht ungerade sein? Bei 0xE0FF
Stimmt, wieder eine Falschannahme und Verwechslung mit ARM-Prozessoren
von mir.
> liegt der Reset-Code und mit einem Disassembler sieht man schnell dass> es sich um gültigen Code handelt der zu einem Reset-Handler passt.
Ghidra erkennt diesen Code:
1
RESET XREF[1]: 00fffe(*)
2
00e0ff 87 CLRA
3
00e100 c7 CLRB
4
00e101 18 0b 00 MOVB #0x0,0x10
5
00 10
6
00e106 18 0b 39 MOVB #0x39,DAT_000012
7
00 12
8
00e10b 18 0b 30 MOVB #0x30,0x11
9
00 11
10
00e110 cf 1f ff LDS #0x1fff
11
00e113 16 e2 6a JSR offset SUB_7fe26a
12
LAB_00e116 XREF[1]: 00e116(j)
13
00e116 20 fe BRA LAB_00e116
und gibt auch eine Pseudo C-Code alternative dafür:
/* WARNING: Do nothing block with infinite loop */
13
} while( true );
14
}
Vermutlich habe ich bei Ghidra was falsch gemacht, denn der Aufruf der
Subroutine mit JSR ab Adresse 0xE113 nennt Ghidra "SUB_7fe26a" und
normalerweise wird hier die Zieladresse als 16 Bit Wert übergeben
(Mnemonic 16 = JSR, gefolgt von HH und LL als Zielmarke des Calls). An
0xE26A geht es also wirklich weiter.
Aber gut, das sieht soweit alles stimmig aus, unabhängig davon was der
Code so alles macht :-)
Dieter schrieb:> Ich würde jeweils die komplette 16 kByte Page lesen (also 0x..BFFF als> Ende, ebenso die komplette Page bei 0x4000 und 0xC000)
Das habe ich ja oben bereits getan. 0x4000 ist ja im Full-Dump drin und
wird vom VBF beschrieben, ebenso 0xC000. Interessant sind ja die
gepageten 16K Bereiche des Flash. Und hier werden vom VBF vier Pages
beschrieben, 0x38, 0x39, 0x3C und 0x3D. Meine Erwartung war das diese
1:1 zur Firmware im VBF passen, was aber interessanterweise nicht der
Fall ist. Was ich nochmal ausprobieren sollte, ist das 9M2J Modul mit
dem VBF "frisch" zu programmieren und dann nochmal zu schauen.
> Und als Vergleich den XPROG Dump nehmen weil der vermutlich> passt.
In meinem ersten Vergleich konnte ich ja doch keinen Unterschied
zwischen dem XPROG Readout und dem vom USBDM feststellen. XPROG wäre
dann vermutlich sinnvoller wenn es um das entschlüsseln eines
Backdoor-Keys ginge, aber ich habe hier bislang keine Anzeichen gesehen
das irgendwas speziell gesichert wäre, Du?
> Und man könnte auch noch den EEPROM lesen, mit der Initialisierung und
Den EEPROM habe ich oben ebenfalls schon angefügt. Dieser ist nicht
Bestandteil des VBF, also wird entweder voll dynamisch zur Laufzeit
genutzt, oder ist Teil der Grundbetankung des Moduls. Das könnte ich mal
verifizieren indem ich das EEPROM des 9M2J Moduls lösche und schaue ob
es dann noch funktioniert, bzw. den Inhalt restauriert. Ich weiss das
wenn man das Modul als erstes mal im Fahrzeug aktiviert, es sich auf
dieses "einstellt" und vermutlich u.a. die VIN dort ablegt. Man erhält
dazu sogar einen Hinweis im Display des Radios das man nun die Zündung
ausschalten, 10 Sekunden warten und diese wieder einschalten soll. Was
ich etwas komisch finde ist, das dieser Meldetext nirgendwo im Flash/VBF
zu finden ist. Er kommt definitiv vom Modul und nicht vom Radio, da ich
das auf dem "Labortisch" mit einem einfachen Monitor bereits mal
nachgestellt hatte.
> dem Bereich ab 0x1000.
Was würde man hier erhalten? 0x1000-0x1FFF ist doch RAM und da kann ja
erstmal nichts sinnvolles drinstehen? Die RESET-Routine intialisiert den
SP auf 0x1FFF.
Olli Z. schrieb:>> Was würde man hier erhalten? 0x1000-0x1FFF ist doch RAM und da kann ja> erstmal nichts sinnvolles drinstehen? Die RESET-Routine intialisiert den> SP auf 0x1FFF.
Und wieder hilft das Datenblatt. Die unter dem Link beschriebene Lösung
mit USBDM initialisiert INITEE (0x12) so dass der EEPROM ab 0x1000
eingeblendet wird. Den Werte muss man gegebenenfalls anpassen, je nach
Chip.
Mein Hinweis mit dem Auslesen von kompletten 16 KByte Pages mit USBDM
versucht auszuschliessen dass USBM eventuell Fehler macht wenn man so
krumme Werte vewendet wie bei Deinem Versuch (das macht in der Praxis
auch wenig Sinn weil man üblicherweise den kompletten Flash lesen will).
Olli Z. schrieb:> Die Software muss das Bank-Paging ja mitmachen bei ihren Sprung und> Adressbefehlen, es ist also vermutlich egal ob die Software "linear"> über die Flash-Blöcke und Pages verteilt ist oder nicht. Die Pages 0x3E> und 0x3F (beides aus Block 0) liegen immer im Adressbereich der CPU.> Diese Pages würden sich dann vermutlich besonders für Library-Funktion> oder (statische)Variablen eignen die jederzeit im Zugriff sein müssen.> Die anderen Pages (0x38, 0x39, 0x3C, 0x3D) dann eher für Programmcode.
Wenn du mehr Programmcode (incl. konstante Daten) hast, als du in den
linear sichtbaren 3 (je 16kB großen) Flash-Segmenten unterbringen
kannst, kommt Paging ins Spiel. Wenn du nur Code in die Pages
platzierst, gehts relativ transparent (soll heissen: ohne dass du
manuell am PPAGE Register rumspielen musst):
Die Funktionen, die in den Page-Bereich sollen, werden für den Compiler
entsprechend deklariert ("far" oder was immer auch der verwendete
Compiler als Schüsselwort verlangt). Dann werden die betreffenden
Funktionen+Aufrufe nicht mehr mit den Maschinenbefehlen
JSR(16BitAdr)/RTS, sondern mit Call(PPage,16BitAdr)/RTC erzeugt. Call
sichert (zusätzlich zu JSR) den alten PPAGE Registerinhalt auf dem Stack
und setzt das PPAGE Register entsprechend der Ziel-Funktionsadresse, RTC
restauriert das PPAGE Register wieder.
Das ist auf C-Quellcodeebene voll transparent, du musst dich nicht um
das PPAGE Register kümmern. Im Linkerskript musst du dann noch dafür
sorgen dass die Paged-Funktionen im entsprechenden Speicherbereich
platziert werden.
Dieter schrieb:>> Was würde man hier erhalten? 0x1000-0x1FFF ist doch RAM und da kann ja> Und wieder hilft das Datenblatt. Die unter dem Link beschriebene Lösung> mit USBDM initialisiert INITEE (0x12) so dass der EEPROM ab 0x1000> eingeblendet wird. Den Werte muss man gegebenenfalls anpassen, je nach> Chip.
Ok, verstanden. Aber laut Datenblatt dürfte das nicht
funktionieren:"device memory map of the MC9S12DT128 after reset. Note
that after reset the EEPROM ($0000 – $07FF) is hidden by the register
space ($0000 - $03FF) and the RAM ($0000 - $1FFF). The bottom 1K Bytes
of RAM ($0000 - $03FF) are hidden by the register space."
Ich lese da raus: Das EEPROM wird vom Register-Space und vom RAM
überlagert und zwar vollständig und immer.
Selbst wenn ich die Base-Address vom MMC für das EEPROM auf 0x1000
stelle, liegt das RAM dennoch da drüber. Und genau das Ergebnis erhalte
ich wenn ich einen Readout mache wie eingestellt. Damit das funktioniert
müsste ich doch eigentlich das RAM-Mapping disablen, oder des
Flash-Mapping und die EEPROM-Adresse (INITEE) auf 0x41 stellen damit es
ab 0x4000 dargestellt wird?
Olli Z. schrieb:>> Damit das funktioniert> müsste ich doch eigentlich das RAM-Mapping disablen, oder des> Flash-Mapping und die EEPROM-Adresse (INITEE) auf 0x41 stellen damit es> ab 0x4000 dargestellt wird?
Ich habe ja geschrieben dass Du das Beispiel aus dem Link gegebenenfalls
an Deinen Chip anpassen musst. Du könntest es z.B. mit dem Wert aus dem
Reset-Code versuchen (0x39, also dann EEPROM ab 0x3800). Eventuell ist
noch mehr Initialisierung nötig, das sollte USBDM können.
Nein, klappt auch nicht. Ich erhalte wieder nur RAM.
Habe schon versucht den unteren Flash-Map zu entfernen mit 0x0F auf das
MISC-Register (0x13), ebenfalls erfolglos.
Das RAM kann man nicht disablen, theoretisch nur kleiner machen, das
lese ich mir gerade durch.
Auch versuche ich weiter aus dem RESET (INIT)-Code schlau zu werden das
dort so getrieben wird...
1
ROM:E101 movb #0, INITRM
2
ROM:E106 movb #$39, INITEE ; '9'
3
ROM:E10B movb #$30, INITRG ; '0'
Das setzt den Start vom 2k RAM-Array auf die Basisadresse 0x0000 (was ja
eh schon der Fall ist nach dem Reset).
Dann das EEPROM auf Start 0x3800 und den Register-Space auf 0x3000.
Auch wenn ich das in die INIT-Sequenz vom USBDM gebe bekomme ich nach
wie vor dasselbe Ergebnis als wenn ich FLAT 0x0000 bis 0xFFFF auslese.
Wenn ich bei USBDM mit "Initialize" Speicherbereiche beschreibe/ändere,
dann finde ich das reflektiert im readout. Soweit scheint die Funktion
zu tun was sie soll.
Was mich bei der ganzen Geschichte noch irritiert ist das der
Register-Space nur zum Teil mit den nach einem RESET erwarteten Daten
übereinstimmt. Die spannenden Daten befinden sich im Bereich
0x0000-0x003F und der sieht nach einem "Flat" readout so aus:
Laut Datenblatt sollten hier nach dem RESET auch einige Read-Only Werte
vom Mikrocontroller stehen, z.B. in 0x1A, 0x1B die Device ID oder in
0x1C, 0x1D die Memory size. Dort ist aber immer nur 0x00 zu lesen. Das
kann doch eigentlich nicht sein?!
Olli Z. schrieb:>> Laut Datenblatt sollten hier nach dem RESET auch einige Read-Only Werte> vom Mikrocontroller stehen, z.B. in 0x1A, 0x1B die Device ID oder in> 0x1C, 0x1D die Memory size. Dort ist aber immer nur 0x00 zu lesen. Das> kann doch eigentlich nicht sein?!
Du wirst vermutlich ein wenig mit den Werten fuer die Initialisierung
von INITRM, INITEE und INITRG experimentieren müssen. Ich würde es
selber ausprobieren, aber ich habe kein Gerät mit dem Chip aus Deiner
ECU hier.
Dieter schrieb:> Du wirst vermutlich ein wenig mit den Werten fuer die Initialisierung> von INITRM, INITEE und INITRG experimentieren müssen. Ich würde es> selber ausprobieren, aber ich habe kein Gerät mit dem Chip aus Deiner> ECU hier.
Danke für die Hilfsbereitschaft Dieter, ich weiss das wirklich sehr zu
schätzen!! Ich habe bereits Stunden mit rumexperimentieren verbracht.
Ich wollte z.B. wissen ob ich es im unteren Bereich wirklich nur mit RAM
zu tun habe und habe daher die Speicherstellen 0x0400, 0x1FFF, 0x2000
mittels der Intialize-Funktion von USBDM mit Daten befüllt:
(400,44),(1FFF,AA),(2000,55)
Der Readout hat gezeigt das bis auf die Speicherstelle 0x2000 alle
anderen mit meinen Daten gefüllt waren. Also liegt das 8KB RAM wirklich
im Adressbereich 0x0000-0x1FFF ("sichtbar" davon sind 0x0400-0x1FFF).
Somit wäre der Adressbereich 0x2000-0x3FFF frei verfügbar. Ich habe also
mittel Initialize das EEPROM auf 0x2000 (INITEE = 0x21) gelegt:
(12,21)
Das EEPROM ist ja nur 2KB groß, müsste sich also von 0x2000-0x27FF
erstrecken. Aber der ausgelesene Bereich ist komplett 0x00 (also
eigentlich auch nicht leer, denn das wäre ja 0xFF). Ab 0x3800 jedoch
kommt immer dieser Code:
Und für mich sieht das irgendwie so aus als wären das EEPROM Daten. Auch
weil doch im Programmcode der EEPROM-Bereich mit 0x39 initilaisiert
wurde, also auf Adresse 0x3800 gelegt. Das würde alles passen. Demnach
wären dann auf 0x2000 doch noch RAM und das ist initial halt 0x00 und
nicht wie bei Flash/EEPROM 0xFF.
Ich glaube irgendwie das die Software schon startet bevor BDM zuschlägt
und dann sind die Verhältnisse so wie sie sind. Zudem wäre auch die
Frage ob es wirklich ausreicht einfach nur die Register zu setzen, oder
ob es nicht noch wenigstens einen CPU-Cycle braucht damit das wirkt.
Oder die Änderung wird aus einem anderen Grund nicht angewendet. Ich
hätte erwartet das nach dem setzen des Registers der Code per Map dort
zu sehen ist wo ich ihn haben wollte.
Nun, man könnte nun ein paar Bytes Maschinencode irgendwo ins RAM
planzen und den ausführen lassen, welcher dann die gewünschten
Einstellungen vornimmt. Dazu müsste man aber einen echten Debugger
verbinden (GDB). Das einzige was USBDM hier in seiner Suite mitbringt
ist eine TCL-Shell, keinen GDB-Server für HCS12. Die sieht so aus wie
man das von JTAG beim Segger kennt (J-Commander). Man kann dort auch
Speicherbereiche lesen/schreiben, aber leider keine programmausführung
(step) durchführen, dabei erhält man ein "Expected BDM command ACK
missing", also irgendwas stimmt nicht:
APW schrieb:> Sicher, dass das ab 0x0000 noch der Registerblock ist und dieser nicht> schon woanders hin geschoben wurde?
Tja, die Init-Routine im Flash macht da ja so einiges und es scheint
wirklich als wäre die schon gelaufen wenn der BDM zuschlägt. Von daher
glaube ich das der BDM den Chip irgendwo "mittendrin" erwischt und so
sieht es auch aus.
Dennoch müssten meine Initialisierungen ja eine Wirkung haben und das
haben sie nicht.
1
ROM:E0FF ; =============== S U B R O U T I N E =======================================
Demnach wird das RAM ab 0x0000-0x1FFF gelegt (das habe ich ja mit meinen
Random-Writes bewiesen), das Register-Space auf 0x0000-0x03FF und das
EEPROM auf 0x3800-3FFF. Die Flash-Pages sind nicht veränderbar.
Es kann natürlich sein das es hier ein Softwarebug ist, denn USBDM ist
ja kein Original NXP Produkt und auch mein Tester ist ein China-Clone.
Olli Z. schrieb:>> Es kann natürlich sein das es hier ein Softwarebug ist, denn USBDM ist> ja kein Original NXP Produkt und auch mein Tester ist ein China-Clone.
Das würde ich ausschliessen (zumindest dass die Clone Hardware das
Problem ist). BDM selbst ist relativ einfach aufgebaut (die Details
stehen in der Doku), da kann man nicht viel falsch machen um die paar
Kommandos zum Chip zu schicken.
Hardware mit dem Chip aus Deiner ECU gibt es leider eher selten, und der
HCS12 ist auch schon älter daher ist es nicht so einfach ein System zum
Testen zu finden. Ich kenne XPROG und den USBDM (auch als Clone) von
diversen anderen HCS12 Varianten, da gab es bisher keine Probleme.
Die Register, mit denen man die Address-Positionen für die
EE/Ram/Register-Blöcke einstellt sind Write-Once (Also nach dem Reset
nur einmal beschreibbar und danach schreibgeschützt), es sei denn, man
startet in einem "Special Mode" (üblicherweise Special Single Chip).
Dann hält der BDM (-Debugger) die CPU nach einem Reset am ersten Befehl
an.
APW schrieb:> Die Register, mit denen man die Address-Positionen für die> EE/Ram/Register-Blöcke einstellt sind Write-Once (Also nach dem Reset> nur einmal beschreibbar und danach schreibgeschützt), es sei denn, man> startet in einem "Special Mode" (üblicherweise Special Single Chip).
Ich glaube da kommen wir der Sache schon näher... hatte das auch gelesen
bei der Lektüre des BDM-Kapitels.
Aber auch das mit dem Special Mode könnte eine gute Erklärung für die
Beobachtungen sein. Das Datenblatt schreib hierzu: "Bits EE11-EE15 are
Write once in Normal and Emulation modes and write anytime in Special
modes"
Dort steht auch das je nach Modus nicht alle BDM-Kommandos aktiv sind.
BDM unterscheidet ja zwischen Hardware- und Firmware-Kommandos. Bei
ersteren kann man zwar ohne CPU Zugriff nehmen, aber nur auf
Speicherbereiche und z.B. nicht auf das Register-Space. Erst wenn man
BDM Firmware aktiviert (da ist wohl noch etwas in einem kleinen ROM im
Chip fest verankert) dann kann man auch Debugging-Kommandos nutzen. Hier
muss ich nochmal ansetzen.
Das Datenblatt schreibt: "The operating mode out of reset is determined
by the states of the MODC, MODB, and MODA pins during reset. The MODC,
MODB, and MODA bits in the MODE register show the current operating mode
and provide limited mode switching during operation. The states of the
MODC, MODB, and MODA pins are latched into these bits on the rising edge
of the reset signal. The ROMCTL signal allows the setting of the ROMON
bit in the MISC register thus controlling whether the internal Flash is
visible in the memory map. ROMON = 1 mean the Flash is visible in the
memory map. The state of the ROMCTL pin is latched into the ROMON bit in
the MISC register on the rising edge of the reset signal."
Damit ich in den Special Mode komme brauche ich an MODA und MODB nichts
zu ändern, die bleiben LOW. Lediglich der BKGD-Pin, welcher auch MODC
ist, müsste zum Zeitpunkt des RESETs LOW sein. Diesen Pin steuert jedoch
USBDM und das müsste es dann aktiv so tun, sonst komme ich in diesen
Modus nicht rein. Zumindest im Memory-Dump-Tool gibt es keine Option
dafür, vielleicht in der TCL-Shell...
> Dann hält der BDM (-Debugger) die CPU nach einem Reset am ersten Befehl> an.
Genau so würde ich es mir wünschen :-)
Dieter schrieb:> Das würde ich ausschliessen (zumindest dass die Clone Hardware das> Problem ist). BDM selbst ist relativ einfach aufgebaut (die Details> stehen in der Doku), da kann man nicht viel falsch machen um die paar> Kommandos zum Chip zu schicken.>> Hardware mit dem Chip aus Deiner ECU gibt es leider eher selten, und der
Zumindest bei Ford findet man den massenhaft in den Baujahren 2007-2014.
Dort in PAM (Einparkwarner), BCM (Komfortsteuereinheit), CMR
(Rückfahrkamerasystem), PCM (Motorsteuerung), AHCU (Standheizung), usw.
usw.
> HCS12 ist auch schon älter daher ist es nicht so einfach ein System zum> Testen zu finden. Ich kenne XPROG und den USBDM (auch als Clone) von
Ja, stimmt sicher, dazu müsste man ein paar alte Teile haben.
> diversen anderen HCS12 Varianten, da gab es bisher keine Probleme.
Ich weiss ja auch garnicht ob ich ein Problem habe oder nur auf der
falschen Fährte bin. Bislang habe ich ja nur ausgelesen und versucht zu
verstehen wie das Zeug tickt um beim Programmieren nicht was
irreversibel zu zerstören.
Beim PAM z.B. gibt es zwei sonst baugleiche Platinen, nur der Chip ist
anders, einmal ist ein MC9S12DG128 drauf und einmal ein MC9S12XD128. Das
heißt einmal HCS12 und einmal HCS12X, zwei völlig verschiedene Chips.
Ich könnte mir aber vorstellen das der Hersteller einfach das nimmt was
grad verfügbar und günstig zu haben ist und die Chipspezifischen
Unterschiede hier gar keine so große Rolle spielen, sprich sich der µC
nach außen hin immer gleich verhält.
Möglicherweise ist durch meine Art des Auslesens schon alles soweit
richtig eingestellt, RAM ist ab 0x1FFF abwärts, EEPROM ab 0x3800
aufwärts und somit im Dump vorhanden. Auch das Pagen scheint ja zu
klappen. Gut möglich das ich hier wirklich schon alles habe um mal einen
Programmierversuch zu wagen.
Trotzdem ist es sehr interessant und spannend sich mit all diesen
Details zu beschäftigen. Und ich hoffe das Du mir inzwischen glaubst das
ich das auch gewillt bin zu tun :-)
Ich habe nun mal ein paar Varianten durchgespielt und danach immer den
Bereich ab 0x3800 ausgelesen ("wb 0x3800 0x100") um zu sehen ob dort
wieder EEPROM Daten zu lesen sind. Leider ist das so, was bedeutet das
der RESET nicht so gegriffen hat. Ich muss das mal mit dem Oszi
untersuchen.
S12 und S12X sind nicht so ohne weiteres austauschbar. Wenn ich mich
richtig erinnere, ist der S12X CPU-Core an mehreren Stellen
weiterentwickelt (Befehlssatz, Ausführungszeiten etc.), teilweise haben
die Chips einen XGATE Coprozessor drauf und das Interruptsystem wurde
umgekrempelt. Irgendwann wurden die Fuzzy-Support-Befehle rausgenommen.
Da gibt es innerhalb der S12X auch mehrere Unterversionen.
Man muss immer vom konkreten Chip ausgehen, und in dessen Datenblatt
nachschauen, u.a. welche CPU-Version da implementiert ist.
Bez. Peripheriemodule, BDM Schnittstelle, XGATE Copro etc. gibt es auch
immer mal unterschiedliche Versionen. Das ist alles im konkreten
Datenblatt aufgelistet.
Bei Freescale (jetzt NXP) gibt (oder gab? war schon lange nicht mehr
dort) alte kostenlose codesizebegrenzte CodeWarrior
Entwicklungsumgebungen für HCS08/HC12/S12/S12X. Da war eine brauchbare
Debuggingumgebung mit dabei. Was man da heute bekommt, musst du selber
nachsehen. Mit S12 habe ich mich vor >10 Jahren zum letzten Mal
beschäftigt.
Ja, danke. Ich wollte jetzt auch nicht das Problem unnötig vergrößern
mit dem HCS12X, nur drauf hinweisen das ich auch solch ein Modul habe.
Ist aber egal, mein Problem ist mit dem HCS12. Und ja, der ist alt. Aber
ich stehe nunmal auf so Retro-Zeugs, egal ob VHS-Technik, alte Computer
oder alte Mikrocontroller :-)
Olli Z. schrieb:>> Zumindest bei Ford findet man den massenhaft in den Baujahren 2007-2014.> Dort in PAM (Einparkwarner), BCM (Komfortsteuereinheit), CMR> (Rückfahrkamerasystem), PCM (Motorsteuerung), AHCU (Standheizung), usw.> usw.
Hast Du Teilenummern dazu, idealerweise von ECUs die man gebraucht
günstig bekommt? Und es sollte der HCS12 sein, nicht der HCS12X, davon
habe ich diverse ECUs von anderen Herstellern hier.
Olli Z. schrieb:>> Ich weiss ja auch garnicht ob ich ein Problem habe oder nur auf der> falschen Fährte bin. Bislang habe ich ja nur ausgelesen und versucht zu> verstehen wie das Zeug tickt um beim Programmieren nicht was> irreversibel zu zerstören.
Wenn Du sowieso den XPROG hast und es Dir darum geht die Firmware der
beiden ECU Varianten auszutauschen sollte es damit kein Problem sein. So
wie ich es verstanden habe sind es ja die selben Chips auf den beiden
ECUs. Ob die restliche Hardware der ECUs dann auch zur anderen Firmware
passt ist etwas anderes.
Olli Z. schrieb:> Ja, danke. Ich wollte jetzt auch nicht das Problem unnötig vergrößern> mit dem HCS12X, nur drauf hinweisen das ich auch solch ein Modul habe.> Ist aber egal, mein Problem ist mit dem HCS12. Und ja, der ist alt. Aber> ich stehe nunmal auf so Retro-Zeugs, egal ob VHS-Technik, alte Computer> oder alte Mikrocontroller :-)
HCS12 war einer meiner Lieblingscontroller.
Wenn die modernere, flexiblere Peripherie drin gehabt hätten, würde ich
die heute noch verwenden wollen.
Boards zum Rumspielen und Entwicklertools habe ich übrigens gerne von
hier bezogen:
https://elmicro.com/catalog/mcu/hc12/
Dieter schrieb:> Hast Du Teilenummern dazu, idealerweise von ECUs die man gebraucht> günstig bekommt? Und es sollte der HCS12 sein, nicht der HCS12X, davon> habe ich diverse ECUs von anderen Herstellern hier.
Das PAM dürfte das günstigste und häufigste sein (gibt es ab so 30€) mit
dem HCS12 ist das BS7T-15K866-AE, das 7G92-15K866-AF ist baugleich (und
billiger und häufiger zu finden).
Olli Z. schrieb:>> Das PAM dürfte das günstigste und häufigste sein (gibt es ab so 30€) mit> dem HCS12 ist das BS7T-15K866-AE, das 7G92-15K866-AF ist baugleich (und> billiger und häufiger zu finden).
Danke. Auf der bekannten Verkaufsplatform findet man einige
BS7T-15K866-AE,
die andere eher selten. Eventuell hole ich mir dort eine von den
BS7T-15K866-AE, mal schauen.
APW schrieb:>> Boards zum Rumspielen und Entwicklertools habe ich übrigens gerne von> hier bezogen:> https://elmicro.com/catalog/mcu/hc12/
Interessant, einige der Boards scheinen immer noch lieferbar zu sein
(wenn auch nicht gerade günstig).
So, habe dem RESET-Vorgang mal mit einem DSO auf die Pins geschaut.
Mittels dem TCL-Interpreter kann man verschiedenste Reset-Methoden
aufrufen, witzigerweise erzeugen alle dasselbe RESET-Bild.
Ansich wäre das ja nicht verkehrt, denn somit kommt der Chip immer in
den Special Single Chip Mode, wenn da nur nicht der parasitäre
nachfolgende Reset-Impuls wäre. Der sorg meines Erachtens dafür das dann
doch im Normal Single Chip Mode gestartet wird.
Wo könnte der her stammen? Komisch auch die Amplitude, hat fast was
Tri-State-Artiges.
Natürlich habe ich auch versucht die Pins manuell zu beeinflussen. In
der Tat sorgt ein "pinSet RST=L" dafür das die RESET-Leitung auf LOW
gezogen wird, ebenso wie ein "pinSet BKGD=L". Dummerweise verweigert
USBDM jedoch die RESET-Leitung mit "pinSet RST=H" wieder hochzuziehen,
dann kommt nur die oben schon genannte dusselige Fehlermeldung.
Interessant ist, das wenn ich RESET und BKGD einfach manuell auf GND
ziehe und dann RESET wieder freigebe (BKGD noch auf GND) dann habe ich
bei RESET den im Bild "rst_bkgd_pulse.png" sichtbaren "Selbstreset".
Könnte es sein das der RESET-Pin auch dann kurz Richtung LOW geht, wenn
es intern einen durch Software ausgelösten RESET gibt? Watchdog, oder
sowas? So lange ich die BKGD-Leitung auf GND lasse, kommt dieser Puls.
Es könnte ja durchaus sein das die Software intern immer dann einen
RESET ausführt wenn das MODE-Register (in dem sollte ja der beim reset
gewählte Chip-Mode enthalten sein) nicht den gewünschten Wert (Normal
Single Chip) aufweist? Das würde in gewisser Weise Sinn ergeben.
Aber wie schafft es die Software dann zu starten wenn ich zunächst in
den Special Single Chip Mode resette? Danach müsste die CPU doch
eigentlich gestoppt bleiben?
Hier liegen wohl die Sourcen von den ganzen Tools:
https://github.com/podonoghue/usbdm-eclipse-makefiles-build-4.10.6.250
und hier die vom TCL Interpreter:
https://github.com/podonoghue/usbdm-eclipse-makefiles-build/tree/master/UsbdmTcl_DLL
Ich durchwühle jetzt mal den Code, vielleicht fällt mir was auf...
Ja, wie vermutet finde ich das im Datenblatt:
2.3.2 RESET — External Reset Pin
An active low bidirectional control signal, it acts as an input to
initialize the MCU to a known start-up
state, and an output when an internal MCU function causes a reset.
Also ist der zweite Reset-Puls aufgrund eines intern ausgelösten Reset.
Jetzt ist nur die Frage wie und warum?
Habe nochmal das BDM-Manual durchgelesen und etwas rumprobiert.
BDM hat eigene Statusregister welche nur für die BDM-Schnittstelle
sichtbar sind. BDM bietet zwei Kommandos um auf diese Register
zuzugreifen READ_BD und WRITE_BD. Angesprochen werden die Register über
Pseudo-Speicheradressen im Bereich von 0xFF00-0XFF0B (diese liegen nicht
in der Memory-Map der CPU, sondern nur des BDM!). Der TCL-Interpreter
realisiert diese Kommandos mit
"rdreg" und "wrreg", jeweils gefolgt von der Speicheradresse.
Im Datenblatt sind für uns interessant, 0xFF01 (BDMSTST) und 0xFF07
(BDMINR) (siehe Grafik). Das erste gibt das BDM-Status-Register an.
Dieses lässt sich dann so ermitteln:
1
% rdreg 0xFF01
2
:rDreg addr=0xFF01(BDMSTS)->0x00000080
3
128
Entspricht 0b1000 0000. Das spricht erstmal dafür das BDM enabled ist
(ENBDM=1) aber NICHT aktiv (BDMACT=0). Wäre das der Fall, so wären wir
im "Special Single Chip Mode". Da BDM nicht aktiv ist, erklärt das auch
warum die ganzen Debugging-Funktionen nicht klappen und nur die
Speicherzugriffe.
Das UNSEC=0 zeigt eigentlich an das sich der Chip im Secured Mode
befindet. Hmm...
Als nächstes habe ich mir das BDMINR vorgenommen, welches im
TCL-Interpreter
warum auch immer als "BDMCCRH" angezeigt wird:
1
% rdreg 0xFF07
2
:rDreg addr=0xFF07(BDMCCRH)->0x00000030
3
48
Diese Register ist im Grunde ein Spiegel des INITRG-Registers im
Register-Space, jedoch ohne das dort befindliche ROMON-Bit. Somit wird
aktuell der Register-Space nach 0x3000 gemapped!
Das wollte ich dann mal genauer wissen und habe mir den Speicherbereich
mit "rb" ausgelesen:
Von besonderem Interesse war für mich dabei zunächst das Byte 0x1A und
0x1B vom Registerspace, also 0x301A und 0x301B, weil dort nämlich die
Device-ID stehen muss, welche ich auf 0x001A und 0x001B nie gefunden
hab, als ich noch davon ausging das der Register-Space ab 0x0000 steht.
Und hier haben wir jetzt endlich 0x0115, eine gültige Device-ID !
Die MEMSIZE-Bytes habe hier auch die richtigen Werte:
MEMSIZ0=0x13
MEMSIZ1=0x80
Das MODE-Byte, welches den Chip-Modus anzeigt ist dann auf 0x300B und
hat hier den Wert 0x80 (0b1000 0000) und demnach ist MODC=1, MODB=0 und
MODA=0, was dem "Normal Single Chip Mode" entspricht.
Damit ist wohl bestätigt das es mir bislang nicht gelungen ist den Chip
in den Special Mode zu resetten und somit auch immer der interne
Programmcode aufgerufen wurde, welche für das vorliegende Memory-Layout
verantwortlich ist. Vermutlich ist er auch verantwortlich für die
RESETs. Wenn man sich den Codeverlauf mit IDA oder Ghidra mal anschaut
wird man das vermutlich herausfinden.
Klar ist somit dann auch das in den bisherigen Dumps der Register-Space
in 0x3000-0x33FF, das EEPROM in 0x3800-0x3FFF und das RAM in
0x0000-0x1FFF lag, weil dies auch der INIT-Prozedur der Software
entspricht:
Olli Z. schrieb:>> Es bleibt also unterm Strich noch die Frage warum mir der Special Mode> nicht gelingen mag. Alles andere funktioniert offensichtlich wie> erwartet.
Du könntest Dir ansehen was XPROG beim Reset macht. Und gegebenenfalls
auch noch mit einen Logicanalyzer schauen was bei BDM passiert, das ist
dann aber etwas nehr Zeitaufwand. Ansonsten solltest Du ja auch so mit
USBDM an den kompletten Flash kommen, man kann ja alle Pages über das
Page Window auslesen.
Alles richtig Dieter. Mein Ansinnen ist es das wirklich zu verstehen
bevor ich mich an die erste Programmierung wage, denn dann kommen sicher
wieder andere Probleme zum Vorschein :-) XPROG brauche ich wohl dann
wenn es darum geht die Sicherung des Chips zu knacken. Aktuell sieht es
ja so aus als würde eine Sperre verhindern das man dem Chip auf die
Finger, äh Register schauen kann ;-)
Olli Z. schrieb:
> ... warum auch immer als "BDMCCRH" angezeigt wird: ...
Dein Tool scheint von neueren Versionen der HCS12/S12X Reihe auszugehen.
Im 9S12XDP512 zum Beispiel gibt es statt "BDMCCR" ein Registerpaar
"BDMCCRL/BDMCCRH".
Im HCS12CoreUG.pdf (Document "S12CPU15UG/D", "STAR12 V1.5 Core User
Guide Version1.2", Revision vom 17.7.2000) habe ich im Kapitel "Section
15 Secured Mode of Operation","15.4.3 Unsecuring The System" folgenden
Satz gefunden:
Please note that if the system goes through a reset condition prior to
successful configuration of unsecured mode the system will reset back
into secured mode operation.
Wobei mir nicht klar ist, 1. ob damit ein HW-Reset gemeint ist oder
einfach das Umschalten vom "Special Single Chip Mode" in den "Normal
Single Chip Mode". Und 2. falls HW-Reset, wie genau dieser Reset
ausgelöst wird. In dem Dokument ist ja auch der Firmware-Quellcode für
Secured und Unsecured BDM gelistet. Dass irgendwo ein Reset ausgelöst
werden würde, ist für mich da nicht rauszulesen.
"Secured" heisst, dass Flash und EEPROM gegen Auslesen geschützt ist und
lediglich der Zugriff auf den Register-Speicherbereich möglich ist
(zwecks Flash/EE löschen oder über Backdoor-Key zu unsecuren). Aber du
hast die Bereiche auslesen können!?
Quellcode gegen Auslesen zu schützten war für mich nie ein Thema,
deshalb kenne ich mich da schlecht aus.
XPROG erzeugt einen sauberen RESET und es folgt dann auch nichts mehr
nach. So hätte ich es auch bei USBDM erwartet. Nach dem Reset in den
Special Mode kommt kein Reset mehr danach. Diesen schiebe ich immer noch
darauf das der Chip, warum auch immer mit USBDM nicht sauber in den
Special Mode kommt und nach der steigenden Flanke von /RESET das
Programm anfängt zu laufen und dann aufgrund von Abfragen in einen
Selbstreset geht.
XPROG liest auch sauber das EEPROM (es entspricht dem was im USBDM Dump
ab 0x3800-0x3FFF steht) und Flash. Beim Flash-Dump von XPROG ist der
Bereich von 0x0000-0x7FFF mit 0xFF gefüllt, wobei ich mir nicht ganz
sicher bin ob XPROG das nur für das Dump so abspeichert, weil es in der
Infobox ganz klar angibt nur die Flash-Pages zu lesen. Ich gehe daher
davon aus das dies nur Füllbytes sind.
In XPROG habe ich die "unsecured" Auslesemethode gewählt.
XPROG liest mit 8MHz, was aber wohl keinen Unterschied macht zu den 4MHz
von USBDM?
Olli Z. schrieb:>> Nach dem Reset in den Special Mode kommt kein Reset mehr danach. Diesen> schiebe ich immer noch darauf das der Chip, warum auch immer mit USBDM> nicht sauber in den Special Mode kommt und nach der steigenden Flanke von> /RESET das Programm anfängt zu laufen und dann aufgrund von Abfragen in> einen Selbstreset geht.
Eine mögliche Erklärung ist dass USBDM das Progamm nicht anhält nach dem
Reset sondern laufen läßt, XPROG dagegen hält es an. Dadurch hat man
dann die Konfiguration, die das Programm einstellt, BDM funktioniert ja
auch bei laufendem Programm.
Ich werde das morgen mal prüfen, ich habe hier inzwischen ein Board mit
einem sehr ähnlichen Chip. Du könntest natürlich auch bei Deiner ECU
schauen, ich weiss nicht ob die z.B. im Betrieb CAN Messages verschickt.
Wenn die auch verschickt werden wenn USBDM den Speicher dumpt dann läuft
die Software, bei XPROG sollte dagegen nichts zu sehen sein.
Wie schon geschrieben, momentan ist das noch eine reine Spekulation.
Ein Unterschied ist das XPROG zuerst RESET auf low legt und erst dann
die Betriebsspannung (Vdd) anlegt. Bei USBDM ist die Betriebsspannung
permanent angelegt. Und wenn ich mir den Schaltplan vom USBDM so ansehe
sieht das auch sehr danach aus als wäre das bei USBDM garnicht
vorgesehen da der Pin auf permanent 5V liegt.
https://github.com/DeuceEFI/USBDM/blob/master/USBDM-Schematic.pdf
Habe das mit meiner USBDM-Hardware mal verglichen. Da ist nur noch
zusätzlich ein 3,3V Spannungsregler und ein Jumper auf dem Board um auch
diese Spannung liefern zu können, aber prinzipiell wird das an USB
ankommende +5V direkt zum BDM-Pfostenstecker weitergereicht, so wie im
obigen Schaltplan.
Damit ist klar, das der USBDM nicht in der Lage ist die Betriebsspannung
ein/aus zu schalten und der TCL-Befehl "settargetvdd" mit den Optionen
0, 3, 5, on, off hier keine Wirkung hat.
Das CMR-Modul sendet von sich aus keine CAN-Botschaften, aber es
antwortet natürlich auf entsprechende Nachrichten. Für Low-Level-Tests
nehme ich da gern Basis-Dienste wie OBD-II Modulinfos oder DTCs. Diese
CAN-Botschaft zum Beispiel initialisiert eine DTC-Abfrage zum Modul:
1
ID DLC DATA
2
7C1 8 03 19 01 8F 00 00 00 00
Das Modul antwortet darauf mit:
1
ID DLC DATA
2
7C9 8 06 59 01 FF 00 00 04 00
Die Antwort kann natürlich variieren bei einer DTC-Abfrage, aber hier
geht es ja nur grundsätzlich darum DAS das Modul antwortet, denn dann
läuft die Firmware. Setze ich mit "pinSet RST=L" die Reset-Leitung auf
low, kommt, erwartungsgemäß, keine Antwort.
Wenn ich jetzt über die TCL-Shell einen "reset s h" (oder irgendeinen
anderen Reset durchführe der das Modul eigentlich in den Special Mode
bringen soll) erhalte ich weiterhin abfragen vom Modul. D.H. das es
wieder in den Normal Mode resettet ist.
Während dem auslesen des Flash mittels USBDM kommen ebenfalls die
CAN-Antworten. D.H. ich lese während die Software läuft.
Ich habe das Gefühl das sich der Chip, nachdem er einmal mit Power-On in
den Normal Mode gebootet wurde, nicht mehr in einen anderen Mode
"warm"resetten lässt.
Olli Z. schrieb:>> Während dem auslesen des Flash mittels USBDM kommen ebenfalls die> CAN-Antworten. D.H. ich lese während die Software läuft.
Wenn ich Dich richtig verstanden habe versorgst Du bei USBDM den Chip
über das USBDM Interface mit Spannung. Falls ja, könnte es damit
zusammenenhängen?
Bei meinem USBDM kann ich per Jumper einstellen ob +5 Volt, +3.3 Volt
oder keine Spannung an den Vcc Pin geht, die Default Einstellung ist
"keine Spannung".
Falls es daran nicht liegt: Auf den Bildern der ECU kann man ja noch
einen anderen Mikrocontroller erkennen (BlackFin DSP). Könnte der
eventuell einen Reset erzeugen wenn er mitbekommt dass der HCS12 nicht
reagiert?
Ein Problem mit USBDM könnte auch sein das der davon ausgeht das der
Register-Space ab 0x0000 liegt, weil er seiner Ansicht nach den Chip
zurückgesetzt hat und das der Default ist. In meinem Fall aber wird
durch den zweiten Reset in den Normal Mode die Firmware aktiviert welche
den Register-Space auf 0x3000 legt.
Es bleibt dabei, das USBDM so nicht in der Lage ist den Chip in den
Special Mode zu bekommen. Es müsste aktiv die Stromversorgung steuern
(so wie XPROG das auch macht). Denn nur wenn man einen Kaltstart
durchführt und dabei die RST und BKGD auf LOW legt bevor man 5V anlegt,
kann das mit dem Special Mode funktionieren. Andernfalls verbleiben
womöglich vorher durch die Firmware gesetzte Watchdogs im Chip aktiv und
führen zum Reset.
Dieter schrieb:> Wenn ich Dich richtig verstanden habe versorgst Du bei USBDM den Chip> über das USBDM Interface mit Spannung. Falls ja, könnte es damit> zusammenenhängen?
Ganz genau.
> Bei meinem USBDM kann ich per Jumper einstellen ob +5 Volt, +3.3 Volt> oder keine Spannung an den Vcc Pin geht, die Default Einstellung ist> "keine Spannung".
Das kann ich auch. Dieser Jumper ist auch bei mir vorhanden.
> Falls es daran nicht liegt: Auf den Bildern der ECU kann man ja noch> einen anderen Mikrocontroller erkennen (BlackFin DSP). Könnte der> eventuell einen Reset erzeugen wenn er mitbekommt dass der HCS12 nicht> reagiert?
Daran habe ich auch schon gedacht, auch an externe
Watchdogs/Spannungsprüfer. Das Problem ist nur, dann hätte XPROG ja das
gleiche Verhalten zeigen müssen.
Was ja auch komisch ist, das wenn BKGD auf LOW bleibt und RESET wieder
HIGH wird, das alles 250ms intern ein Reset ausgelöst wird. Das sehe ich
ganz deutlich auf dem Oszi.
Olli Z. schrieb:>> Das kann ich auch. Dieser Jumper ist auch bei mir vorhanden.>
Ich habe hier vermutlich eine ältere Version des USBDM, der kann z.B.
auch kein ARM SWD, siehe das Bild.
Ich habe das Verhalten inzwischen mit meinem HCS12 Board ausprobiert,
dort ist die CPU angehalten wenn USBDM den Speicher dumpt, man muss
explizit nach dem Lesen einen Reset ausführen um die Software im HCS12
nach dem Lesen mit USBDM wieder zu starten. Die Software ist
USBDM_4_12_1_262_Win.
Nochmal zu XPROG: dort läuft die ECU Software nicht, also ist keine CAN
Kommunikation möglich?
Ich nehme inzwischen an dass ein externer Reset dazwischen funkt. Was
hat denn der 6-Pin SOT-23 an der linken unteren Ecke des HCS12 für eine
Bezeichnung?
Die Frage ist warum XPROG keine Probleme mit dem externen Reset hat, da
wäre interessant zu wissen ob beim Auslesen mit XPROG die Firmware in
der ECU ebenfalls läuft.
Dieter schrieb:> Ich nehme inzwischen an dass ein externer Reset dazwischen funkt. Was
Diese Vermutung hattest Du ja schon früher und lagst damit auch
goldrichtig, wie ich nun weiss :-)
> hat denn der 6-Pin SOT-23 an der linken unteren Ecke des HCS12 für eine> Bezeichnung?
Der ist es nicht, aber auf der gegenüberliegenden Seite ist ein
Voltage-Monitor/Watchdog Baustein (5) vom Typ (SMD-Marking "PKG4",
SOT-23-5) TPS3820-50DBVRQ1G4. Dessen /RESET-Ausgang ist über einen 4,7k
Widerstand auf den /RESET der MCU (und des Debug-Headers) verbunden. Der
Voltage-Monitor wird ebenfalls mit Vdd (+5V) gespeist und läuft somit
auch an wenn man die Vdd extern über den USBDM anlegt. Durch den
Vorwiderstand und eine Leistungsaufnahme kann er den RESET nicht ganz
bis auf GND-Level ziehen, das ist der "schwache" Reset-Impuls den wir
ganz am Anfang sehen (Einschalt-Reset) und der der 25ms später kommt
(Watchdog-Reset).
Damit kein Reset ausgelöst wird müsste der Chip regelmäßig über den
WDI-Eingang mit einer geänderten Flanke versorgt werden. Der WDI ist
direkt mit dem Pin 23 (PB7) der MCU verbunden.
Wie Du schon richtig vermutet hast sorgt die MCU mit einem regelmäßigen
Flankenwechsel auf PB7 dafür das der Watchdog-Timer zurückgesetzt wird
und somit nicht zuschlägt. Bleiben die Impulse 25 ms aus, wird ein RESET
ausgelöst.
Nun habe ich so auf die Schnelle keine Möglichkeit gesehen den Watchdog
zu "entschärfen" und einfach den 4,7k Widerstand ("472") zum BDM-Header
hin ausgelötet und siehe da - alles funktioniert wie es soll!
Ich kann mit einem normalen "reset" im TCL-Interpreter den Chip in den
Special Mode bringen, die Register auslesen und habe auch das erwartete
Memory-Layout:
1
% reset
2
:reset 0x1C(DEFAULT, SPECIAL)
3
% connect
4
:connect
5
BDM status => Ackn, Speed-sync, Vpp-Off, Vdd-External, RSTO=1, Reset, CFVx-running
In einem Full-Readout mit allen Pages finde ich nun auch die komplette
aus dem VBF stammende Firmware 1:1 wieder :-)
So, nun kann ich mich endlich dran machen den Chip so einzustellen das
man auch das EEPROM vollständig auslesen kann. Auch glaube ich jetzt
genug zu wissen um mal einen Programmierversuch zu starten.
Die Sache mit dem Reset hat jetzt schon echt genervt. Laut Datenblatt
vom Watchdog-Chip ist es wohl so, das der Watchdog disabled wird, wenn
der WDI-Eingang Hochohmig (unbeschaltet) ist. Sobald dieser einen LOW
(GND) oder HIGH (5V) Pegel hat, wird er gestartet:
"If WDI remains high or low longer than the time-out period, then reset
is triggered. The timer clears when reset is asserted or when WDI sees a
rising edge or a falling edge. If unused, the WDI connection must be
high impedance to prevent it from causing a reset event."
Dazu müsste man den PB7 hochohmig als Tri-State programmieren, oder als
Eingang ohne Push/Pull-Widerstand. Das würde ggf. durch Beschaltung der
Register funktionieren. Laut Datenblatt vom MC9S12 sollten aber
eigentlich sämtliche Ausgänge hochohmig (3state) sein nach dem Reset.
Damit ist dieses Problem ja nun gelöst. Wobei ich denke dass man den
externen Reset auch über die Debug Testpads unschädlich machen kann ohne
auf der Platine löten zu müssen. Eventuell reicht ja schon ein
zusätzlicher Pullup Widerstand an Reset um den externen Reset nicht
durchkommen zu lassen.
Und XPROG wird vermutlich den Reset Pegel so stark auf "High" halten
dass der externe Reset nicht durchkommt.
Dieter schrieb:> Damit ist dieses Problem ja nun gelöst.
Ja, war ne harte Nuss und ich Danke Dir für deine unermüdliche
Unterstützung!!
Jetzt so im Nachhinein erinnere ich mich an einen alten Trick, wenn man
sehen wollte ob ein Impuls von einem bestimmten Baustein kam, (z.B. bei
W-Bus, K-Line, CAN) dann hat man da einfach einen Widerstand in die
Leitung geklemmt und konnte dann an den unterschiedlichen Pegeln
erkennen was von wem gesteuert wurde. Im Prinzip ist das hier beim RESET
auf der Fall gewesen :-)
> Wobei ich denke dass man den> externen Reset auch über die Debug Testpads unschädlich machen kann ohne> auf der Platine löten zu müssen. Eventuell reicht ja schon ein> zusätzlicher Pullup Widerstand an Reset um den externen Reset nicht> durchkommen zu lassen.
Einen solchen Gedanken hatte ich auch schon. Direkt oben links neben dem
Widerstand sieht man ja einen TP (im Prinzip der TP vom /RESET Ausgang).
Evtl. könnte man hier eine Brücke nach +5V machen sodass der Watchdog
den Ausgang nicht auf LOW bekommt. Oder wie Du sagst am RESET-Pin des
BDM-Headers mit einem niederohmigen Widerstand (z.B. 1k) auf +5V dafür
zu sorgen das der Watchdog das über den 4,7k nicht schafft einen Pegel
der tief genug für den Reset der MCU ist herzustellen.
Ich hatte ein wenig gehofft das es ähnlich wie bei anderen Modulen mit
Watchdog hier einen Disable-Pin am Header gibt der das auslösen des
Reset direkt oder über einen Transistor verhindert. Aber da finde ich
nix. Einzig das vom RESET-Pin der MPU neben dem direkten Pin am Header
noch der gegenüberliegende mit Reset versorgt wird, welches aber über
einen Widerstand in Reihe und einen Kondensator gegen Masse läuft. Den
Sinn dafür habe ich noch nicht verstanden.
> Und XPROG wird vermutlich den Reset Pegel so stark auf "High" halten> dass der externe Reset nicht durchkommt.
Das wäre eine Erklärung warum es da nicht auftritt. Der Watchdog selbst
läuft ja in jedem Fall. In der Firmware müsste man wohl auch einen
Timer-Interrupt finden welcher den PB7 immer wieder toggelt um den
Watchdog am leben zu halten.
Wenn ich den "regs" Befehl eingebe sieht man ja den Zustand der internen
Register (zum Glück hat die HCS12 CPU nicht so viele davon ;-) aber auch
den Program-Counter:
1
regs
2
PC =4A4D, D = 0, X = 0, Y = 0, SP = 0,
3
PC = 0x4A4D : 0x80E6 0x801B
Warum der wohl auf 0x4A4D steht? Laut Datenblatt wird im Special Mode
die CPU direkt nach dem Reset angehalten, noch vor Ausführung des ersten
Befehls. Ich hätte also erwartet das sich die CPU den Reset-Vektor auf
0xFFFE liest (welcher auch 0xE0FF weist) und diesen Wert in den PC lädt.
Auch sagen mir die Werte dahinter noch nix, könnte das Stack sein?
Olli Z. schrieb:>> Auch sagen mir die Werte dahinter noch nix, könnte das Stack sein?
Schau halt mal in Deinem Dump an diese Adresse: USBDM zeigt die Werte am
PC an, einen Disassembler gibt es vermutlich in USBDM nicht.
Der "seltsame" Wert des PC ist vermutlich eine Konstante "JM" könnte ein
Heiweis auf den Entwickler sein. Den Wert verwenden andere HCS12
Varianten ebenfalls.
Also es reicht wenn ich den /RESET-Pin vom BDM-Header des Boards über
einen 1k Widerstand auf Vdd (+5V) ziehe. Dann hat der Watchdog über
seinen 4,7k Widerstand keine Chance mehr den Pegel weiter als 0,5V unter
Vdd zu ziehen. Damit wird dann kein Reset mehr ausgelöst und man kann
die MCU ganz ohne auslöten eines Bauteils in den Special Mode bringen.
Dieter, evtl. hast Du hierzu auch ein paar wertvolle Hinweise und Tipps?
Beitrag "HCS12 (MC9S12DG) dump mit IDA Pro disassemblieren"
Wollte das Thema nicht hier in dem Thread behandeln, weil ich glaube das
es den Rahmen sprengen könnte.
Ich habe gestern einige Teile der Firmware dekodiert und bin überrascht
wie unterschiedlich die Dinge in der 8M2J und 9M2J Firmware behandelt
werden. Da liegt aber auch bei der Entwicklung mind. 1 Jahr dazwischen,
möglicherweise wurde die Toolchain aktualisiert/getauscht.
Der INIT nach dem Reset sieht bei der 8M2J Firmware nämlich so aus:
1
ROM:FC95 ; public _Reset
2
ROM:FC95 _Reset: ; DATA XREF: USER_VEC:FFFE↓o
3
ROM:FC95 ldaa byte_FAA2 ; CONST Value for INITRG (Register-Space start at 0x3000)
4
ROM:FC98 ldx word_FAA0 ; CONST Address of INITRG
5
ROM:FC9B staa 0,x ; Store 0x30 at 0x11 (INITRG)
6
ROM:FC9B ; = Register-Space starts at 0x3000
7
ROM:FC9D ldaa #$3D ; '='
8
ROM:FC9F staa byte_3030 ; Set PPAGE to 0x3D
9
ROM:FCA2 lds #$2000 ; Init SP to 0x2000 in RAM
10
ROM:FCA5 ldaa byte_FAA3 ; CONST Value for INITRM (RAM start a 0x0000)
11
ROM:FCA8 staa byte_3010 ; Set INITRM to 0x00
12
ROM:FCAB ldaa byte_FAA4 ; CONST Value for INITEE (EEPROM start at 0x3800)
13
ROM:FCAE staa byte_3012 ; Set INITEE to 0x39
14
ROM:FCB1 ldaa byte_FAA5 ; CONST Value for MISC (0x01)
15
ROM:FCB4 staa byte_3013 ; Set MISC to ROMON (Flash visible in memory map)
16
ROM:FCB7 ldaa byte_FAA6 ; CONST Value für COPCTL (0x04)
17
ROM:FCBA staa byte_303C ; Set COPCTL to watchdog timeout in 262.144 OSCCLK cycles (~32ms)
18
ROM:FCBD ldaa #0
19
ROM:FCBF staa PORTB ; Set PORTA Pins (PA0-7) to LOW
20
ROM:FCC2 staa PORTA ; Set PORTB pins (PB0-7) to LOW
21
ROM:FCC5 brclr byte_FA9F, #$80, loc_FCCD ; Byte an memloc is 0x83, so goto jsr
22
ROM:FCCA jsr wait_until_PLL_locked
Anschließend wartet der Code bis der PLL eingerastet ist, führt dann
einige Memory-Tests durch und geht dann in eine Endlosschleife,
vermutlich die Serverloop (main()) in der immer wieder der externe und
interne Watchdog zurückgesetzt wird. Weitere direkte Aussprünge kann ich
so noch nicht erkennen, jedoch wird immer etwas überprüft und
konditionell verzweigt. Ggf. wird da anstelle mit direkten Calls/Jumps
mit dem Stack gespielt, oder es ist alles in Timern/Interrupts vergraben
und diese Loop überwacht nur den Betriebszustand. Hier und da gibt es
Absprünge in Endlosschleifen (bra auf sich selbst) was dann nach kurzer
Zeit wohl unweigerlich zum Reset durch den Watchdog führt.
Olli Z. schrieb:> Dieter, evtl. hast Du hierzu auch ein paar wertvolle Hinweise und Tipps?> Beitrag "HCS12 (MC9S12DG) dump mit IDA Pro disassemblieren"
IDA Pro kann mit den Pages ganz gut umgehen, man muss dazu
passende Segment in IDA Pro konfigurieren. Wie das genau
geht wird z.B. im Support Forum für IDA Pro Kunden erklärt.
Ich habe jetzt aber nicht vor hier den Support für IDA Pro
zu machen und die Freeware Version von IDA Pro kann den
HCS12 meines Wissens sowieso nicht.
Ansonsten halt bei Ghidra schauen, da müsste es auch gehen,
dazu kenne ich allerdings nicht die Details.
Dieter schrieb:> IDA Pro kann mit den Pages ganz gut umgehen, man muss dazu> passende Segment in IDA Pro konfigurieren. Wie das genau
Alles gut, habs schon :-)
Ghidra kann es z.B. nicht, bzw. nur halb.
IMG_3913.JPG
(240 KB)
cmr_bdm_header.png
(590 KB)
mc9s12_qfp80_pinout.png
(200 KB)
operation_mode.png
(47 KB)
