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?
Übrigens: Wenn du 0x0000 in 0xYFFA21 schreibst, veränderst du möglicherweise den WD-Prescaler (Faktor 512 schneller, wenn SWP-Bit = "0" ist).
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?
Angehängte Dateien:
-
bild_1.jpg
380 KB -
bild_2.jpg
460 KB
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.
Nur aus Interesse .... Hat dein "Projekt" mit Chip-Tuning zu tun ?
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.