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


von Rolf F. (Gast)


Angehängte Dateien:

Lesenswert?

Nach der Installation des mspgcc (s. Installations-Skript im Anhang)
funktioniert zwar Compilieren, Linken, Laden des Codes in den MC, aber
nicht das Debuggen.
Nach dem Start des Debuggers mit

ddd --debugger msp430-gdb test1.elf

meldet er:

(gdb) target remote localhost:2000
0x00001100 in reset_vector_ ()
(gdb) monitor erase all
Erasing target flash - all... Erased OK
(gdb) load
Loading section .text, size 0x7c lma 0x1100
Loading section .vectors, size 0x20 lma 0xffe0
Start address 0x1100, load size 156
Transfer rate: 1248 bits/sec, 39 bytes/write.
(gdb) monitor reset
Resetting... Reset OK
(gdb) run
Don't know how to run.  Try "help target".
(gdb)

Und mit der letzten Meldung findet msp430-gdbproxy den MC plötzlich
nicht mehr, obwohl das Flaschen funktionierte:

info:      msp430: Target device is a 'MSP430F149' (type 7)
notice:    msp430-gdbproxy: waiting on TCP port 2000
notice:    msp430-gdbproxy: connected
error:     msp430: Could not find device (or device not supported) (4)
info:      msp430-gdbproxy: session killed. Will wait for a new
connection

Ich habe das Beispiel und die anderen Sachen von der MSPGCC-Seite hier
übernommen, überprüft (auch auf Tippfehler) und es mehrmals probiert,
aber keine Änderung.

Woran kann es liegen, dass es nicht richtig funktioniert?

von OldBug (Gast)


Lesenswert?

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

von Rolf F. (Gast)


Lesenswert?

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

von OldBug (Gast)


Lesenswert?

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

von Rolf F. (Gast)


Lesenswert?

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?

von Jörg Wunsch (Gast)


Lesenswert?

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

von Rolf F. (Gast)


Lesenswert?

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.

von Jörg Wunsch (Gast)


Lesenswert?

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.

von Rolf F. (Gast)


Lesenswert?

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

von OldBug (Gast)


Lesenswert?

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

von Jörg Wunsch (Gast)


Lesenswert?

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

von R2D2 (Gast)


Lesenswert?

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

Bitte 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
Noch kein Account? Hier anmelden.