msp430-gdb: Don't know how to run. Try "help target".

Hallo Rolf!

Beim "load" musst Du das hex-File angeben. Das elf-File wird vom
Debugger zum Auflösen der Symbole usw benötigt. Der Mikrocontroller
benötigt dann das hex-File.

(gdb) load test1.elf.a43

Bei mir heissen die immer .elf.a43, war im Beispielmakefile so und ich
habs nie geändert...

Gruß,
Patrick...

Dann brauche ich diese magische Makefile, denn ohne funktioniert es bei
mir nicht.
Häng' die doch mal bitte hier in's Forum.

Hi!

Du wirst doch ein Intel-Hex-File von Deinem Projekt haben!?

Naja, die Zeile sieht so aus:

msp430-objcopy -O ihex xyz.elf xyz.elf.a43

Gruß,
Patrick...

Also:

a) msp430-gcc -mmcu=msp430x149 -g -O -o test1.elf test1.c

b) msp430-objcopy -O ihex test1.elf aout.elf.a43

c) ddd --debugger msp430-gdb test1.elf

d) load aout.elf.a43

=> gleicher Fehler

Und das auf 2 PCs mit neu installiertem MSPGCC.

Alles geht, bis auf Debuggen; wo ist der Fehler?

Weiß nicht, wie der Monitor beim MSP430 funktioniert, aber beim
AVR-GDB darf man kein `run' eingeben, sondern nur `continue'.

Aha. Damit geht es, danke :)

Aber wo ist das denn dokumentiert?
Ich habe mir ja die MSPGCC-Seite hier durchgelesen u. das Handbuch zum
MSPGCC, aber immer nur run und nie continue gefunden.

Keine Ahnung.  Logisch ist es aber:

> (gdb) target remote localhost:2000
> 0x00001100 in reset_vector_ ()

Damit zeigt er ja an, daß er sich bereits im laufenden Target auf
Adresse 0x1100 befindet und dort angehalten hat.  Das ist ungefähr so,
wie wenn Du einen laufenden Unix-Prozeß mittels `attach' debugst oder
einen laufenden Unix-Kernel (einer anderen Maschine) via `target
remote' -- die entsprechenden Programme befinden sich bereits in der
Ausführung, Deine aktuelle Aktion hat sie eben angehalten, aber im
Prinzip kannst Du sie nur (sinnvoll) fortsetzen, nicht neu starten.

Selbst wenn Deine Umgebung ein `run' gestattet (Unix-Prozeß mit
`attach'), würde ein `run' den soeben debuggten Prozeß aufgeben (via
`detach' wieder sich selbst überlassen) und eine neue Debug-Instanz
starten.

`run' ist aber IMHO nur sinnvoll, wenn der Debugger den Code native
ausführen kann (also host == target ist).

Wie geschrieben: ich kenne die Toolchain für den MSP430 nicht, aber
die GNU Tools selbst halt schon seit einigen Jahren.

Aha. Bisher kenne ich halt nur run auf PC/ARM und die IDEs die ich
bisher kenne (auch die für MSP430), verwenden auch nur run.
Nachdem ich nochmal nachgesehen habe, konnte ich es doch dokumentiert
finden: http://mspgcc.sourceforge.net/manual/x1602.html :-o

Das hatte ich natürlich überlesen!
Aber das .elf wirst Du wohl kaum per "load" rüberschicken können,
oder?
Ging bei mir jedenfalls nicht :(

Gruß,
Patrick...

P.S.: Beim nächsten Mal bitte einen kürzeren Betreff g

> Aber das .elf wirst Du wohl kaum per "load" rüberschicken können,
> oder?

Zumindest beim AVR-GDB funktioniert das schon.  Der GDB lädt das
ELF-File, mittels `load' schiebt er dann die davon nötigen Teile
entweder via AVaRICE zum JTAG ICE (und damit zum Controller) bzw.  zum
simulavr.

Das ELF file kannst du problemlos per load hochladen.
Ich hab nicht mal ne Option in meinem Makefile die HEX erzeugen würde.
So geht's:
file xxx.elf
tar r :2000
mon erase main
load
cont


R2D2