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?
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
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.