Hi,
ich habe ein Problem mit den GNU-Tools zum debuggen des msp430. Konkret:
Ich habe Eclipse wie in der Anleitung auf dieser Seite eingerichtet. Das
Kompilieren funktioniert problemlos, nur das debuggen funktioniert
nicht.
Dabei startet der msp430-gdbproxy (unter Windows) problemlos und erkennt
das Ziel (msp430f1611). Beim initieren der Debug-Sitzung zeigt das
gdbproxy-Fenster auch "connected" o.ä. an. Auf jeden Fall bleibt eclipse
dann hängen und gibt nach einiger Zeit eine Fehlermeldung aus...
Unter Linux habe ich exakt das gleiche Fehlerverhalten.
Dabei funktioniert das herunterladen des Programms mit dem
"msp430-downloader.exe" unter Windows einwandfrei. Unter Linux habe ich
Versuche mit "ddd" angestellt, hier klappt das herunterladen mittels des
entsprechenden gdb-Befehls (wenn auch langsam), nur beim eingeben von
"continue" tut sich nichts mehr.
Dachte zuerst an ein Problem mit dem Parallel-Port (fest im Laptop
installiert), aber sowohl mit dem IAR-Compiler als auch mit dem "TI
CodeComposerEssentials" funktioniert das Debuggen absolut problemlos,
leider ist mein Programm größer als die freien Versionen dieser
Programme es zulassen.
Der JTAG-Adapter ist übrigens dieses Standard-FET für den Parallel-Port.
Falls jemand eine Idee hat, woran das liegen könnte, wäre ich sehr
dankbar... Ist etwas nervig, über 3 LEDs zu debuggen. Mittels Forensuche
und Google konnte ich leider keine Lösung finden.
Danke & Gruß,
Christian
...und gleich noch eine kleine Frage hinterher:
Wo kann man denn das Programm "msp430-jtag" für linux finden? Bei meiner
mspgcc-distribution war es nicht dabei, und bei einer gerade
stattgefundenen google-suche konnte ich es nicht finden.
Ich hoffe, ich gehe richtig in der Annahme, daß dies das Programm ist um
unter Linux .elf-Dateien in den msp herunterzuladen?
Danke,
Christian
Hi,
so ein Zufall, hatte erst gestern das gleiche Problem. Bei mir schien's
dran gelegen zu haben, dass ich zu lange Dateipfade, bzw. solche mit
Leerzeichen hatte. Als ich dann mal kurz 'ne zweite HD eingebaut hatte
(Wollte an der anderen nix rumpartitionieren) und diese als
Developing-Laufwerk eingerichtet hatte, ging's plötzlich. Versuch' mal
sowas, vlt. liegt's bei dir ebenfalls daran...
Zur anderen Frage weiss ich leider nix.
Das kommt bei mir auch mal öfters vor. Schalte zuerst mal die
Optimierung ab, also auf -o0, dann Debug auf maximum, und dann gehts
eventuell. Wenn man große Datenfelder über den Debugger holen will, oder
zuviel optimiert wurde, bleibt er hängen. Es kann aber auch sein, dass
du ein großes Array definiert hast, und den WDT nicht VORHER
ausschaltest? Das geht mit low_level_init, schau mal in die Appnotes von
TI, das ist da beschrieben. Wird das Feld initialisiert und ist größer
als 2k, dann schmiert die Kiste ab, weil der WDT dazwischen einen Reset
macht.
> Wo kann man denn das Programm "msp430-jtag" für Linux finden? Bei meiner> mspgcc-Distribution war es nicht dabei, und bei einer gerade> stattgefundenen Google-suche konnte ich es nicht finden.
Das kannst du über CVS bekommen:
$ cvs -d:pserver:anonymous@mspgcc.cvs.sourceforge.net:/cvsroot/mspgcc
login
$ cvs -z3
-d:pserver:anonymous@mspgcc.cvs.sourceforge.net:/cvsroot/mspgcc co jtag
$ cd jtag
$ make
$ sudo make install
$ cvs -d:pserver:anonymous@mspgcc.cvs.sourceforge.net:/cvsroot/mspgcc
login
$ cvs -z3
-d:pserver:anonymous@mspgcc.cvs.sourceforge.net:/cvsroot/mspgcc co
pyjtag
$ cd pyjtag
$ make
$ sudo make install
... oder so ähnlich ...
> Ich hoffe, ich gehe richtig in der Annahme, dass dies das Programm ist um> unter Linux .elf-Dateien in den msp herunterzuladen?
Ja. Es geht zwar auch über gdb/gdbproxy - das ist aber seehr langsam.
>> Ich hoffe, ich gehe richtig in der Annahme, dass dies das Programm ist um>> unter Linux .elf-Dateien in den msp herunterzuladen?>> Ja. Es geht zwar auch über gdb/gdbproxy - das ist aber seehr langsam.
Kommt drauf an. Mit dem TI-USB-FET gehts sauschnell. Mit dem
Parallelport-Frickel-Adapter ziemlich lahm...
Hi,
vielen Dank für die Hinweise.
Am Dateipfad kann es eigentlich nicht liegen, der ist nicht so
wahnsinning lang und Leerzeichen hat er auch keine... Aber ich es werde
es mal versuchen.
Jedoch verstehe ich nicht, was die Partition mit dem Dateipfad zu tun
hat??
Die Optimierung hab ich aus, an dem Rest werd ich mal ein wenig
rumspielen. Das mit der Größe der Variablen ist ein interessanter
Aspekt, ich hab eine Menge globales Zeug. Die Appnote werde ich mal
angucken, daß es ein Watchdog-Timer-Problem sein könnte, hätte ich nicht
gedacht.
Das msp430-jtag werde ich mir wohl runterladen, und über kurz oder lang
den USB-JTAG von TI besorgen. Kostet ja nicht die Welt...
Ich kann das ganze jetzt leider nicht direkt versuchen, da ich das Zeug
nicht hier habe. Werde am Donnerstag mal Bescheid geben, ob es geklappt
hat.
Nochmals Danke & viele Grüße,
Christian
> Das msp430-jtag werde ich mir wohl runterladen, und über kurz oder lang> den USB-JTAG von TI besorgen. Kostet ja nicht die Welt...
Lohnt sich IMHO nicht. Wenn man msp430-jtag statt
msp430-gdb/msp430-gdbproxy benutzt, geht das flashen über den
Parallelport-Adapter auch innerhalb weniger Sekunden satt 20-30 min.
> Lohnt sich IMHO nicht. Wenn man msp430-jtag statt> msp430-gdb/msp430-gdbproxy benutzt, geht das flashen über den> Parallelport-Adapter auch innerhalb weniger Sekunden satt 20-30 min.
Also, 20-30mins hat es bei meinen ddd-Versuchen auch net gedauert ;-)
Vielleicht so 2. Auf jeden Fall so lange, daß man denkt, es ginge gar
nichts mehr...
Hä? Meinen MSP430F1611 flasht der gdb-proxy in ca 10...15 Sekunden über
den Paralleport-Adapter. Irgendwas macht ihr falsch. Der msp430-jtag
braucht ca 10 sekunden. Programmgröße war ca 25kByte. Über den TI-USB
dauerts ca 3...4 Sekunden.
Auch wenn der Thread ein bissl älter ist:
Ich hab dasselbe Problem. Hab bis jetzt den Code Composer verwendet und
bin nun an das Code Size Limit gekommen. Hab dann gestern versucht den
GCC mit Eclipse zu installieren.
Hat auch wunderbar geklappt. Der gdbproxy findet mein Device und
Eclipse/GCC übersetzt mein Programm perfekt. Wenn ich dann Debuggen
will, kommt nach kurzer Zeit eine Fehlermeldung "Target not responding:
Timeout" oder so ähnlich.
Hab dann über die Konsole versucht eine fertige kompilierte Datei
hochzuladen. Selbe Problem. Immer Timeout. In meinem Testprogramm hab
ich nur eine Headerdatei drin + Wachhund ausschalten + main mit while.
Habt ihr ne Lösung zu dem Problem gefunden?
Welche Version (Datum) der GCC Toolchain hast du? Ich hab mit der vom
November 2006 und Februar 2007 arge Probleme. Der USB Debugger schmiert
dauernd ab, das Programm läuft entweder gar nicht los, und/oder lässt
sich dann nicht unterbrechen. Arbeite mit der Version vom 2.5.2006, da
klappt alles.
Habs im Moment grad auch herausgefunden. Aber trotzdem danke. Gut zu
wissen, dass die neueren Versionen nicht funktionieren. Hab die Version
vom 2.5.2006 installiert und plötzlich ging alles. Ein Traum...hab mich
jetzt 2 Tage damit rumgeärgert den GCC zu installieren.
Wie kann ich denn Breakpoints setzen? Ich seh zwar rechts oben das
Fenster "Breakpoints", aber da kann ich nix setzen und mit rechtsklick
auf die Code-stelle finde ich auch keinen Eintrag.
Gibt eigentlich eine Möglichkeit zu sehen, wieviel Speicher aufn µC
verwendet wird?
Arbeitest du mit Eclipse? Dann kannst du BP setzen, indem du auf diese
Leiste links neben den Code-Zeilen doppelkickst.
Speicher anzeigen geht mit: msp430-size --target=elf32-msp430
filename.elf
Okay klappt perfekt. Hab nur noch ein Problem:
Wenn ich debuggen möchte und in eine Funktion reinsteppe, dann kommt
Fehlermeldung. Die Funktionen sind in einer zweiten c-Datei deklariert
und über einen Header in Main eingebunden.
1
while(1)
2
{
3
XAxis=SCA3000E05_AXIS_READ(0x05);//Hier kein Step in die Funktion rein
Was für eine Fehlermeldung denn? Bei sehr komplexen Funktionen in
Unterprogrammen ist der Debugger manchmal überfordert. Ebenso bei
eingeschalteter Optimierung....
