Forum: Fahrzeugelektronik Firmware aus MC9S12 per BDM clonen

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?

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:

1

00004000  06 76 6A 01 00 06 76 0C 01 00 06 78 CD 01 00 06  .vj...v....xÍ...

2

00004010  75 F0 01 00 06 75 F0 01 00 06 78 CA 01 00 06 78  uð...uð...xÊ...x

3

00004020  C9 01 00 06 78 C8 01 00 06 78 C7 01 00 06 78 C6  É...xÈ...xÇ...xÆ

4

00004030  01 00 06 78 C5 01 00 06 78 C4 01 00 06 78 C3 01  ...xÅ...xÄ...xÃ.

5

00004040  00 06 78 C2 01 00 06 78 C1 01 00 06 78 C0 01 00  ..xÂ...xÁ...xÀ..

6

00004050  06 78 BF 01 00 06 78 BE 01 00 06 78 BD 01 00 06  .x¿...x¾...x½...

7

00004060  73 35 01 00 06 78 BB 01 00 06 78 BA 01 00 06 78  s5...x»...xº...x

8

00004070  B9 01 00 06 78 B8 01 00 06 78 B7 01 00 06 78 B6  ¹...x¸...x·...x¶

9

00004080  01 00 06 78 B5 01 00 06 78 B4 01 00 06 76 06 01  ...xµ...x´...v..

10

00004090  00 06 78 B2 01 00 06 78 B1 01 00 06 78 B0 01 00  ..x²...x±...x°..

11

000040A0  06 78 AF 01 00 06 78 AE 01 00 06 78 AD 01 00 06  .x¯...x®...x....

12

000040B0  78 AC 01 00 06 76 05 01 00 06 76 04 01 00 06 75  x¬...v....v....u

13

000040C0  FD 01 00 06 75 F6 01 00 06 78 A7 01 00 06 78 A6  ý...uö...x§...x¦

14

000040D0  01 00 06 78 A5 01 00 06 78 A4 01 00 06 78 A3 01  ...x¥...x¤...x£.

15

000040E0  00 06 78 A2 01 00 06 78 A1 01 00 06 78 A0 01 00  ..x¢...x¡...x ..

16

000040F0  06 78 9F 01 00 06 78 9E 01 00 06 78 9D 01 00 06  .xŸ...xž...x....

17

00004100  78 9C 01 00 06 78 9B 01 00 06 78 9A 01 00 06 78  xœ...x›...xš...x

18

00004110  99 01 00 06 78 98 01 00 06 78 97 01 00 06 78 96  ™...x˜...x—...x–

19

00004120  01 00 06 78 95 01 00 06 78 94 01 00 06 78 93 01  ...x•...x”...x“.

20

00004130  00 06 78 92 01 00 06 78 91 01 00 06 78 90 01 00  ..x’...x‘...x...

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

1

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

2

0007BF00  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FE  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿþ

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

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

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

1

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

2

00007410  39 4D 32 4A 2D 31 39 48 34 30 35 2D 41 42 00 00  9M2J-19H405-AB..

3

00007420  00 00 00 00 00 00 39 4D 32 4A 2D 31 34 46 36 33  ......9M2J-14F63

4

00007430  37 2D 41 42 00 00 00 00 00 00 00 00 00 00 39 4D  7-AB..........9M

5

00007440  32 4A 2D 31 39 48 34 30 35 2D 41 43 00 00 00 00  2J-19H405-AC....

6

00007450  00 00 00 00 00 00 39 4D 32 4A 2D 31 34 46 36 33  ......9M2J-14F63

7

00007460  30 2D 41 42 00 00 00 00 00 00 00 00 00 00 39 4D  0-AB..........9M

8

00007470  32 4A 2D 31 34 46 36 33 31 2D 41 42 00 00 00 00  2J-14F631-AB....

9

00007480  00 00 00 00 00 00 53 59 53 46 4F 52 44 43 44 43  ......SYSFORDCDC

10

00007490  41 52 31 34 00 00 00 00 00 00 00 00 00 00 00 00  AR14............

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:

1

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

2

0000FF80  41 3B 41 36 41 31 41 2C 41 27 41 22 41 1D 41 18  A;A6A1A,A'A"A.A.

3

0000FF90  41 13 41 0E 41 09 41 04 40 FF 40 FA 40 F5 40 F0  A.A.A.A.@ÿ@ú@õ@ð

4

0000FFA0  40 EB 40 E6 40 E1 40 DC 40 D7 40 D2 40 CD 40 C8  @ë@æ@á@Ü@×@Ò@Í@È

5

0000FFB0  40 C3 40 BE 40 B9 40 B4 40 AF 40 AA 40 A5 40 A0  @Ã@¾@¹@´@¯@ª@¥@ 

6

0000FFC0  40 9B 40 96 40 91 40 8C 40 87 40 82 40 7D 40 78  @›@–@‘@Œ@‡@‚@}@x

7

0000FFD0  40 73 40 6E 40 69 40 64 40 5F 40 5A 40 55 40 50  @s@n@i@d@_@Z@U@P

8

0000FFE0  40 4B 40 46 40 41 40 3C 40 37 40 32 40 2D 40 28  @K@F@A@<@7@2@-@(

9

0000FFF0  40 23 40 1E 40 19 40 14 40 0F F2 73 40 05 E0 FF  @#@.@.@.@.òs@.àÿ

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

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:

1

void __asmA_longcall UndefinedFunction_00e0ff(void)

2

3

{

4

  short sVar1;

5

6

  DAT_000012 = 0x39;

7

  DIRECT = 0x30;

8

  sVar1 = LoadStack(0x1fff);

9

  *(undefined2 *)(sVar1 + -2) = 0xe116;

10

  (*(code *)&SUB_7fe26a)(0,0);

11

  do {

12

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

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?

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:

1

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

2

00000000  00 00 00 00 02 02 00 00 00 00 00 00 00 00 00 00  ................

3

00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

4

00000020  50 00 00 00 00 00 00 00 00 00 00 00 22 01 00 00  P..........."...

5

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 01  ................

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

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:

1

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

2

000037D0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

3

000037E0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

4

000037F0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

5

00003800  AA FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ªÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ

6

00003810  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ

7

00003820  32 30 31 30 30 36 31 39 30 30 31 36 00 00 00 00  201006190016....

8

00003830  00 1E 0C 0F 28 25 0F 14 0A F7 93 00 02 01 03 01  ....(%...÷“.....

9

00003840  06 12 00 FF 6A 94 20 00 B6 99 C9 3C 03 18 67 38  ...ÿj” .¶™É<..g8

10

00003850  07 3D DD 04 3E DD 06 C7 11 B7 41 01 5E 03 1A 2A  .=Ý.>Ý.Ç.·A.^..*

11

00003860  38 07 3B DD 04 3A DD 06 C7 0C 8D C3 43 4B 02 50  8.;Ý.:Ý.Ç..ÃCK.P

12

00003870  4C 35 07 37 DD 04 3A DD 06 C7 00 00 00 00 00 00  L5.7Ý.:Ý.Ç......

13

00003880  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

14

00003890  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

15

000038A0  00 00 00 00 00 00 00 00 00 00 00 00 00 CE C8 CE  .............ÎÈÎ

16

000038B0  01 B4 B4 B4 01 16 07 21 06 00 00 00 00 00 00 00  .´´´...!........

17

000038C0  00 00 00 00 00 02 20 80 00 80 00 80 00 80 00 80  ...... €.€.€.€.€

18

000038D0  00 80 00 80 00 80 50 00 00 80 00 84 00 80 00 80  .€.€.€P..€.„.€.€

19

000038E0  00 80 00 80 00 80 00 80 20 80 00 00 00 00 00 00  .€.€.€.€ €......

20

000038F0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

21

00003900  00 00 00 00 00 00 00 00 00 00 00 00 00 00 5D ED  ..............]í

22

00003910  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ

23

00003920  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ

24

00003930  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ

25

00003940  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ

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:

1

USBDMScript incorporating TCL - Copyright(c) 2011

2

Press ? for help

3

===============================================================

4

  usbdm_rc.tcl

5

================

6

  This file is 'sourced' whenever usbdmScript.exe is executed

7

  Add your own custom commands

8

  Type ? for command summary

9

10

  Typical sequence:

11

  settarget arm

12

  openbdm   ;#can add number of reported BDM if needed

13

  connect

14

  regs

15

===============================================================

16

17

% settarget hcs12

18

USBDM DLL Version = 4.12.1.262

19

BDM List:

20

 0 - USBDM-JS16-SWD_SER-0001 : USBDM HCS08,HCS12,CFV1,ARM-SWD BDM

21

Found 1 devices

22

:setTarget HCS12

23

% openbdm

24

Opening USBDM-JS16-SWD_SER-0001

25

BDM Version = HW=97, SW=4C

26

27

% connect

28

:connect

29

BDM status => Ackn, Speed-sync, Vpp-Off, Vdd-External, RSTO=1, No Reset, CFVx-running

30

Speed = 4000 kHz (1920 ticks, sync=32.0 us)

31

Ackn, Speed-sync, Vpp-Off, Vdd-External, RSTO=1, No Reset, CFVx-running

32

% go

33

Expected BDM command ACK missing

34

% regs

35

regs

36

Expected BDM command ACK missing

37

%

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

2

ROM:E0FF

3

ROM:E0FF

4

ROM:E0FF                 ; public _Reset

5

ROM:E0FF _Reset:                                 ; CODE XREF: _COP_failure_reset:loc_F2B5↓p

6

ROM:E0FF                                         ; DATA XREF: USER_VEC:off_FFFE↓o

7

ROM:E0FF                 clra

8

ROM:E100                 clrb

9

ROM:E101                 movb    #0, INITRM

10

ROM:E106                 movb    #$39, INITEE ; '9'

11

ROM:E10B                 movb    #$30, byte_11 ; '0'

12

ROM:E110                 lds     #$1FFF

13

ROM:E113                 jsr     sub_E26A

14

ROM:E116

15

ROM:E116 loc_E116:                               ; CODE XREF: _Reset:loc_E116↓j

16

ROM:E116                 bra     loc_E116

17

ROM:E116 ; End of function _Reset

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.

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

Es sieht ja so aus als könnte man mit dem TCL-Tool einen entsprechenden 
RESET erzeugen:

1

reset <N|S><H|S|P|V|A>       - Reset (N=normal,S=Special), (H=Hardware,S=Software,P=Power,V=Vendor,A=All

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.

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

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

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:

1

% rb 0x3000 0x3FF

2

:rb =>

3

  0x00003000 : 00 88 00 8A 00 00 00 00 17 08 10 80 90 00 01 00

4

  0x00003010 : 00 30 39 01 00 0F 00 10 00 00 01 15 13 80 40 F2

5

  0x00003020 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

6

  0x00003030 : 38 00 BF 00 03 01 00 8C 10 80 E1 50 04 00 80 00

7

  0x00003040 : 00 00 00 00 67 9F A0 00 00 00 00 00 00 05 80 80

8

  0x00003050 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 9C 40

9

  0x00003060 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

10

  0x00003070 : 00 00 00 00 00 00 FF FF 00 00 00 00 00 00 00 00

11

  0x00003080 : 00 00 A0 00 01 10 80 00 01 00 00 FF 00 80 00 7F

12

  0x00003090 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 40

13

  0x000030A0 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

14

  0x000030B0 : 00 00 00 00 FF FF FF FF FF FF FF FF FF FF FF FF

15

  0x000030C0 : FF FF FF FF 00 00 00 00 00 04 00 00 C0 00 00 00

16

  0x000030D0 : 00 04 00 00 C0 00 00 00 5C 02 31 20 00 00 00 00

17

  0x000030E0 : 00 00 00 80 00 00 00 00 C0 00 40 00 47 00 00 00

18

  0x000030F0 : 04 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00

19

  0x00003100 : 00 FE 00 00 D7 C0 00 00 00 00 00 00 00 00 00 00

20

  0x00003110 : A8 00 00 00 FF C0 00 00 00 00 00 00 04 02 30 88

21

  0x00003120 : 00 00 00 20 05 00 00 00 80 00 00 00 00 00 00 FF

22

  0x00003130 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

23

  0x00003140 : 10 80 87 23 00 01 07 00 00 00 00 10 00 00 00 00

24

  0x00003150 : 00 00 FF FF FF E7 00 00 FF FF FF FF 00 00 00 00

25

  0x00003160 : 77 03 14 1C B2 D0 D6 08 63 19 AD 5D 5A 00 3B 49

26

  0x00003170 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

27

  0x00003180 : 01 11 00 00 00 00 07 00 00 00 00 00 00 00 00 00

28

  0x00003190 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

29

  0x000031A0 : AE C7 63 89 99 B5 79 D2 65 BC C9 E6 08 00 68 A9

30

  0x000031B0 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

31

  0x000031C0 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

32

  0x000031D0 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

33

  0x000031E0 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

34

  0x000031F0 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

35

  0x00003200 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

36

  0x00003210 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

37

  0x00003220 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

38

  0x00003230 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

39

  0x00003240 : 00 00 DC 00 00 00 00 00 00 00 00 00 00 FF 00 00

40

  0x00003250 : 03 33 F8 00 00 00 00 10 02 02 AF 00 00 00 00 00

41

  0x00003260 : 00 00 00 00 00 00 00 00 00 00 80 00 00 00 00 03

42

  0x00003270 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

43

  0x00003280 : 01 11 00 00 00 00 07 00 00 00 00 00 00 00 00 00

44

  0x00003290 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

45

  0x000032A0 : 9E 87 CB 41 02 5E 15 9A 3B 37 67 E6 79 00 88 A7

46

  0x000032B0 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

47

  0x000032C0 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

48

  0x000032D0 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

49

  0x000032E0 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

50

  0x000032F0 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

51

  0x00003300 : 81 00 00 00 00 00 00 00 00 00 00 0F 00 00 80 00

52

  0x00003310 : 00 00 00 00 00 FF 00 00 00 00 00 00 00 00 00 00

53

  0x00003320 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

54

  0x00003330 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

55

  0x00003340 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

56

  0x00003350 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

57

  0x00003360 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

58

  0x00003370 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

59

  0x00003380 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

60

  0x00003390 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

61

  0x000033A0 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

62

  0x000033B0 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

63

  0x000033C0 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

64

  0x000033D0 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

65

  0x000033E0 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

66

  0x000033F0 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

67

0

68

%

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:

1

ROM:E0FF                 ; public _Reset

2

ROM:E0FF                 clra

3

ROM:E100                 clrb

4

ROM:E101                 movb    #0, INITRM   ; RAM start 0x0000

5

ROM:E106                 movb    #$39, INITEE ; EEPROM start 0x3800

6

ROM:E10B                 movb    #$30, INITRG ; Register-Space start 0x3000

7

ROM:E110                 lds     #$1FFF       ; Stackpointer

8

ROM:E113                 jsr     sub_E26A

Es bleibt also unterm Strich noch die Frage warum mir der Special Mode 
nicht gelingen mag. Alles andere funktioniert offensichtlich wie 
erwartet.

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

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?

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.

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.

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

6

Speed = 4000 kHz (1920 ticks, sync=32.0 us)

7

Ackn, Speed-sync, Vpp-Off, Vdd-External, RSTO=1, Reset, CFVx-running

8

% regs

9

regs

10

 PC =4A4D,   D =   0,   X =   0,   Y =   0,  SP =   0,

11

PC = 0x4A4D : 0x80E6 0x801B

12

% rb 0x0000 0x100

13

:rb =>

14

  0x00000000 : 00 40 00 00 00 00 00 00 0B 00 00 00 90 00 01 00

15

  0x00000010 : 09 00 01 0D 00 0F 00 10 00 00 01 15 13 80 40 F2

16

  0x00000020 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

17

  0x00000030 : 00 00 BF 00 00 00 00 5C 00 00 F1 00 00 00 80 00

18

  0x00000040 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

19

  0x00000050 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

20

  0x00000060 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

21

  0x00000070 : 00 00 00 00 00 00 FF FF 00 00 00 00 00 00 00 00

22

  0x00000080 : 00 00 00 20 05 00 00 00 80 00 00 00 00 00 00 FF

23

  0x00000090 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

24

  0x000000A0 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

25

  0x000000B0 : 00 00 00 00 FF FF FF FF FF FF FF FF FF FF FF FF

26

  0x000000C0 : FF FF FF FF 00 00 00 00 00 04 00 00 C0 00 00 00

27

  0x000000D0 : 00 04 00 00 C0 00 00 00 04 00 00 20 00 00 00 00

28

  0x000000E0 : 00 00 00 80 00 00 00 00 C0 00 40 00 47 00 00 00

29

  0x000000F0 : 04 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00

30

0

31

% rb 0xFF00 0x100

32

:rb =>

33

  0x0000FF00 : FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FE

34

  0x0000FF10 : FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

35

  0x0000FF20 : FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

36

  0x0000FF30 : FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

37

  0x0000FF40 : FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

38

  0x0000FF50 : 43 47 53 2D 53 31 32 44 47 31 32 38 61 2D 35 2E

39

  0x0000FF60 : 30 34 2E 31 36 00 00 00 33 30 37 33 37 31 36 36

40

  0x0000FF70 : 20 41 46 00 00 00 00 00 00 00 00 00 00 00 00 00

41

  0x0000FF80 : 41 3B 41 36 41 31 41 2C 41 27 41 22 41 1D 41 18

42

  0x0000FF90 : 41 13 41 0E 41 09 41 04 40 FF 40 FA 40 F5 40 F0

43

  0x0000FFA0 : 40 EB 40 E6 40 E1 40 DC 40 D7 40 D2 40 CD 40 C8

44

  0x0000FFB0 : 40 C3 40 BE 40 B9 40 B4 40 AF 40 AA 40 A5 40 A0

45

  0x0000FFC0 : 40 9B 40 96 40 91 40 8C 40 87 40 82 40 7D 40 78

46

  0x0000FFD0 : 40 73 40 6E 40 69 40 64 40 5F 40 5A 40 55 40 50

47

  0x0000FFE0 : 40 4B 40 46 40 41 40 3C 40 37 40 32 40 2D 40 28

48

  0x0000FFF0 : 40 23 40 1E 40 19 40 14 40 0F F2 73 40 05 E0 FF

49

255

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.

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?

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.

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.