BD32 Memory Dump

[curiosity (Gast)]

Hallo,

ich hätte eine Frage an die erfahreneren Mitglieder:
Ich greife mit dem Tool BD32 von Scott Howard unter Windows 98 auf einen 
Mikrocontroller zu und möchte Speicherinhalte in eine Datei auf dem 
Host-PC schreiben. Leider bietet das Tool von Haus aus dazu keine 
Möglichkeit, stattdessen kann man sich einen eigenen "Target-Resident 
Command Driver" in Assembler schreiben, der auf dem Mikrocontroller 
ausgeführt wird und auf von BD32 bereit gestellte System-Calls wie 
FOPEN, FCLOSE, FWRITE zurückgreifen kann. Diese erlauben es, Dateien auf 
dem Host-PC zu schreiben.
Meine Frage ist, ob jemand zufällig schon so eine Erweiterung 
geschrieben hat und sie mir zur Verfügung stellen könnte.
Desweiteren frage ich mich, da der Target-Resident Command Driver ja 
zunächst auf den Mikrocontroller kopiert wird, ob dadurch nicht Teile 
des Speichers, den ich auslesen möchte, überschrieben werden könnten? 
Oder wird dafür immer eine unbenutzte Speicherstelle gewählt?

Vielen Dank im Voraus für eure Antworten.

[alopecosa (Gast)]

Vielleicht solltest du mit dem offensichtlichen Kenntnisstand, aufhören 
zu versuchen Steuergeräte in Autos zu (um)zuprogrammieren

;)

[curiosity (Gast)]

Es geht dabei nicht um Autos. Wie kommst du darauf?

[foobar (Gast)]

> ... möchte Speicherinhalte in eine Datei auf dem Host-PC
> schreiben. Leider bietet das Tool von Haus aus dazu keine
> Möglichkeit,

Wie wär's mit
  LOG dateiname
  MD <start> <length>
  LOG OFF
?

Btw, ich hab ja schon einiges gesehen, aber dieses "Feature", den 
Debugger mittels Code auf der zu debuggenden CPU zu erweitern, ist schon 
ziemlich abgefahren ;-)

[Volker B. (Firma: L-E-A) (vobs)]

foobar schrieb:

> Btw, ich hab ja schon einiges gesehen, aber dieses "Feature", den
> Debugger mittels Code auf der zu debuggenden CPU zu erweitern, ist schon
> ziemlich abgefahren ;-)

Das ist in der Welt der Power-PC-MCUs nicht unüblich. Von NXP und ST 
gibts  jede Menge an Code, der auf dem Targetsystem läuft, z.B. um auf 
der MCU Flash zu löschen, programmieren und verifizieren. Da ein 
wichtiges Einsatzgebiet dieser MCUs Automotive ist, war die Bemerkung 
von alopecosa nicht so abwegig...

Grüßle
Volker

[Dieter (Gast)]

Volker B. schrieb:
>
> Da ein wichtiges Einsatzgebiet dieser MCUs Automotive ist, war die
> Bemerkung von alopecosa nicht so abwegig...

BDM32 ist doch für die CPU32 basierenden Chips von Motorola und nicht 
für die PowerPCs (oder gibt es da eine Variante?). Die Zeiten der CPU32 
im automotive Bereich dürften schon länger vorbei sein (z.B. Saab 
Trionic bis um ca. 2003). Oder gibt es die CPU32 auch noch in 
aktuelleren ECUs, das wäre interessant, mir ist allerdings bisher keine 
untergekommen.

[Volker B. (Firma: L-E-A) (vobs)]

Dieter schrieb:

> BDM32 ist doch für die CPU32 basierenden Chips von Motorola und nicht
> für die PowerPCs (oder gibt es da eine Variante?).

Meine Aussage bezog sich nur auf den von mir zitierten Text: "dieses 
'Feature', den Debugger mittels Code auf der zu debuggenden CPU zu 
erweitern, ist schon ziemlich abgefahren".

Um wieder On-Topic zu werden: NXP hat (noch) CPU32-MCUs im Programm. 
Wenn sich die Frage des TO um eine solche MCU drehen sollte, was mir 
meine Glaskugel leider nicht verrät, würde ich an seiner Stelle dort 
suchen, denn, wie geschrieben, verteilt der Hersteller Code für seine 
PPC32-MCUs und es wäre naheliegend, dass er auch Code für die CPU32-MCUs 
anbietet.

Grüßle
Volker

P.S.: Vielleicht will der TO auch nur seine Orgel "pimpen", vgl. 
Beitrag "MC 68331 im E-Piano"