Hallo zusammen,
ich hoffe, jemand kennt sich noch mit den alten CPU32 von Motorola /
Freescale aus:
Ich möchte einen MC68336 per BDM debuggen. Dazu verwende ich das
(offizielle) BD32 Tool. Nun ist es leider so, dass mein zu debuggendes
Programm den Watchdog aktiviert. Und wenn ich per Einzelschritt durch
das Programm steppe, löst der leider aus (im RSR wird der Watchdog als
Grund eingetragen). Dadurch zeigt mir mein Einzelschritt immer nur die
Reset-Adresse an.
Wenn ich nun versuche, den Watchdog zu deaktivieren (0xYFFA21 auf
0x0000), funktioniert das zunächst auch (der Speicher nimmt den Wert
an). Beim nächsten Einzelschritt aber hängt sich BD32 komplett auf ("No
MCU connection") - es funktioniert gar kein Zugriff mehr.
Hat jemand Erfahrung mit den alten Schätzchen und vielleicht eine Idee,
wo mein Fehler liegt? Was kann ich tun?
Grüße
Steffen
Ich habe mit dem MC68336 noch nicht gearbeitet, aber im User Manual
steht sinngemäss folgendes:
- Der Watchdog ist aus dem Reset heraus bereits aktiv (SWE im SYPCR —
System Protection Control Register ist "1")
- Das SYPCR kann nur EINMAL nach dem Reset beschrieben werden, danach
ist es schreibgeschützt
-Der WD läuft normalerweise beim Debugging weiter, es sei denn, man
setzt das Bit "FRZSW — Freeze Software Enable" im Register "SIMCR —
SIM Configuration Register". Dieses Bit kann man nach einem Reset (bei
dem es "0" gesetzt wird) mehr als einmal schreiben.
Freeze Operation (Auszug aus dem User Manual:
5.2.5 Freeze Operation
The FREEZE signal halts MCU operations during debugging. FREEZE is
asserted internally by the CPU32 if a breakpoint occurs while background
mode is enabled. When FREEZE is asserted, only the bus monitor, software
watchdog, and periodic interrupt timer are affected. The halt monitor
and spurious interrupt monitor continue to operate normally. Setting the
freeze bus monitor (FRZBM) bit in SIMCR disables the bus monitor when
FREEZE is asserted. Setting the freeze software watchdog (FRZSW) bit
disables the software watchdog and the periodic interrupt timer when
FREEZE is asserted.
Vielleicht hilft das?
Vergiss meinen letzten Beitrag!
(Der Prescaler wird verändert, aber der WD ist natürlich auch
deaktiviert. Alles unter der Voraussetzung dass das Register nicht
bereits schreibgeschützt ist)
Ja, das hilft mir viel weiter! In der Beschreibung zum Watchdog (Kapitel
5.4.5) steht nichts davon, dass man ihn nur einmal ändern kann. Aber Du
hast Recht, hinten in der Registerbeschreibung stehts.
Vielen Dank für Deinen Hinweis, ich probiere das aus!
Leider kann mein Debugger (BD32) nicht direkt nach dem Reset stoppen
(der "RESTART" Befehl, der eigentlich dafür vorgesehen ist, wirft eine
Fehlermeldung). Ich muss also davon ausgehen, dass das Programm bereits
losgelaufen ist und das Watchdog-Register bereits gesetzt hat. Dann ist
es logisch, dass meine erneuten Schreibversuche auf das Register
fehlschlagen.
Inzwischen habe ich aber festgestellt, dass ich sporadisch sehr wohl
im Einzelschritt debuggen kann. Ich hab noch keine Regelmäßigkeit
festgestellt, aber wenn man eine Weile "rumspielt", klappt es. Klingt
nach Hardware-Fehler, aber ich habe meinen Aufbau schon x-Mal
durgemessen, die Kabelverbindungen gekürzt (ich verwende einen
selbstgebauten Parallelport-Debugger) und die Logik-ICs getauscht. Keine
Besserung.
Kennst Du Dich (oder vielleicht auch jemand anderes hier) mit dem BDM
aus? Gibt es eine kommerzielle Hardware, die etwas taugt und die man
heute noch kaufen kann?
Mit dem BD32 wirst du nicht weit kommen.
Schau dir mal folgenden Link hier an ....
http://www.mikrocontroller.net/articles/GCC_M68k
da steht schon eine Menge dazu drin ....
Was BDM Mode betrifft ....
https://sourceforge.net/projects/bdm/
Damit kannst du Erfolg haben. Der Schaltplan zum BDM Interface liegt
oben genannten Projekt incl. aller Sourcen bei. Damit kannst nach deinen
Wünschen Breakpoints setzen, Debuggen, single step, variablen, register
....
Ich habe damit eine komplette Umgebung für den 68332 erstellt incl.
Debugging über BDM. Über Parallelport bild_1 oder ganz modern über
Netzwerk bild_2.
Prima! Wenn der Adapter besser funktioniert, werde ich ihn ausprobieren.
Ich wollte ihn sowieso schon einmal nachbauen (Teile inkl. GAL liegen
schon hier), aber ich müsste die Platine noch machen lassen. Du hast
nicht zufälligerweise noch eine über, die Du mir verkaufen möchtest?
Den Beitrag aus der Artikelsammlung zum M68K kenne ich. Der BD32 passt
mir aber insofern gut, als dass ich eh nur Reverse Engineering betreibe
und daher mit Assemblercode arbeite.
Ist denn jetzt der Adapter buggy oder BD32? Oder beide?
Danke für die Tipps :-)
Mit dem BD32 habe ich mal vor 20 Jahren gearbeitet. Mal so zum Hochladen
eines Programms brauchbar. Zum Debuggen unbrauchbar. Die BDM-Timings
werden einfach nicht korrekt eingehalten.
Damals haben wir dann einen Debugger aus der Hitex Linie verwendet.
Diese Dinger waren wirklich gut. Aber auch teuer ;)
Vor 2 Jahren hatte mein Neffe ein Studienprojekt mit der CPU32 am
Laufen. Damals habe ich ein wenig ausgeholfen und mich nochmal intensiv
mit dem BDM geschäftigt. Das Interface aus
https://sourceforge.net/projects/bdm/ ist wirklich gut und brauchbar zum
debuggen. Da haben einige gute Arbeit geleistet. Auch was die Software
betrifft. Einige nützliche Tools zum flashen sind auch dabei.
Nein, Platinen dazu habe ich nicht mehr.
Vielen Dank für Deine Infos!
Ich werde heute die Platine in Auftrag geben lassen und dann den Adapter
bestücken und ausprobieren. Wenn BD32 dann immer noch Schwierigkeiten
macht, wovon ich nach Deinem Post schon ausgehen muss, werde ich zum Gnu
Debugger wechseln.
In meinem Projekt geht übrigens tatsächlich um ein automotive
Steuergerät. Allerdings keine Motorsteuerung (ich nehme an, Du hattest
die Trionic im Sinn?), sondern eine Getriebesteuerung. Und getunt wird
da auch erstmal nix.
@BDM:
Ich habe den Debugger inzwischen fertig. Da BD32 weiterhin nicht so
recht funktioniert, würde ich als nächstes zu GDB wechseln. Aber:
Funktioniert der überhaupt ohne Sourcecode?
Was ich meine: BD32 holt sich seine Daten ja eigenständig über das BDM
aus dem Programmspeicher, disassembliert das dann und zeigt es an.
Dadurch kann man schön durch bereits im ROM existierenden Code steppen.
Da ich reverse engineering betreibe, ist das genau das, was ich brauche.
Funktioniert GDB genauso?
Grüße
Steffen
