So nachdem ich nun endlich mal einen einstieg in eclipse gefunden habe
habe ich natürlich (wie soll es auch anders sein) das erste problem :
Ich kann programme erstellen/compilieren. Das flashen funktioniert auch.
allerdings muß ich dazu im Debugger Configuration Dialog den "mspgcc
debugger" auswählen, und nicht wie im tutorial von liechti den
gdbserver.
sobald ich den gdb-server anwähle und auf "Debug" klicke fängt der an
was zu machen (sehe ich im msp430-gdbproxy den ich per console gestartet
habe), bricht dann aber mit der fehlermeldung
"/cygdrive/c/Programme/eclipse/C:\workspace\msp_test1/C:\workspace\msp_t
est1\msp_test1.elf: No such file or directory." ab. nun weiß ich
allerdings nicht wie dieser kuriose pfad zustande kommt (denn ich habe
cygwin selbst nicht installiert, das kommt wohl vom mspgcc)
wenn ich jedoch den mspgcc debugger verwende kann ich zwar flashen und
auch etwas debuggen, aber wenn ich einen breakpoint setze kommt der da
nie hin (in einer blinker-endlos-schleife z.b.). auch kann ich die debug
session nicht terminieren, der msp-gdb-proxy läuft fröhlich weiter, und
eclipse meldet nach ein paar sekunden timeout, den proxy kann ich nur
mit ctrl+c beenden, und danach muß ich meinen msp von der spannung
trennen und wieder dranmachen damit der gdb-proxy mir kein "device
unknown" meldet)
was mache ich falsch ?! gibt es da ein paar grundsätzliche dinge die ich
übersehen habe ?!
Nun ja, der Debugger is so ne Sache. Der ist nicht wirklich als stabil
zu bezeichnen. Bei mir gehn aber sowohl mspgcc-gdb als auch normal
gdb-server. Allerdings muss man dort auf der einen Tab noch TCP und Port
3333 bei Localhost einstellen.
Im Gegensatz zu der Anleitung geht der Cygwin da nicht.
Welche GCC Version hast du? Die aktuelle Windows-Version klappt bei mir
mit Debuggen überhaipt nicht, die vom November 2006 sehr gut.
Der Debugger hat aber auch ein paar Macken, z.B. eine leere
Endlosschleife lässt sich nicht unterbrechen, also in etwa:
for (;;);
da schmiert der ab. Ebenso bei while(1); und solchen Sachen. Desweiteren
kriegt der disassembler es nicht gebacken, stark optimierten Code mit
dem Quellcode in Verbindung zu bringen -> timeout.
Strom ab und wieder dran, muss ich allerdings selten. Auch der USB
Debugger klappt wunderbar, nur der Eclipse-GDB-Frontend schmiert halt
immer mal ab.
Achja, NICHT den Restart-Knopf drücken....da is wohl nen Bug, das klappt
auch nicht
Wie der komische Pfad zustande kommt, weiß ich nicht, der
Debugger-Assistent sucht doch das Elf-File automatisch.
>Nun ja, der Debugger is so ne Sache. Der ist nicht wirklich als stabil>zu bezeichnen. Bei mir gehn aber sowohl mspgcc-gdb als auch normal>gdb-server. Allerdings muss man dort auf der einen Tab noch TCP und Port>3333 bei Localhost einstellen.
dazu kann ich nur sagen : full ack :-((
>Im Gegensatz zu der Anleitung geht der Cygwin da nicht.
da sagt mir eclipse schon beim einstellen im dialog "cpu not supported"
(kann noch nicht mal auf apply klicken -> nur der gdbserver schluckt
das, läuft aber nicht (richtig), mspgcc GDB läuft, aber halt recht
instabil)
>Welche GCC Version hast du? Die aktuelle Windows-Version klappt bei mir>mit Debuggen überhaipt nicht, die vom November 2006 sehr gut.
habe die vom februar 2007. wenn das die aktuellste ist werde ich mal ein
"downgrade" versuchen. vielleicht hilfts ja.
>Der Debugger hat aber auch ein paar Macken, z.B. eine leere>Endlosschleife lässt sich nicht unterbrechen, also in etwa: for (;;);>da schmiert der ab. Ebenso bei while(1);
aber mit einem stückchen code zwischen dem while(1) und dem ; sollte es
doch funktionieren oder ?
jedenfalls kann ich im laufenden code keine breakpoints setzen (setzen
zwar schon, aber er hält nicht an), aber das kann ja vllt mit der "zu
neuen" gcc version liegen.
>Strom ab und wieder dran, muss ich allerdings selten.
habe ich leider mit bestechender regelmäsigkeit. allerdings immer nur
dann wenn ich den gdb-proxy zwangsterminieren musste (ctrl+c).
nach einem erneuten start des proxies liefert der mir immer "device
unknown"
habe statt den msp fet usb den parallelport, aber das sollte ja nichts
zur sache tun.
>Restart-Knopf
apropos :
gibt es eine möglichkeit den gdb zu re-starten ohne das der jedesmal das
dingen neu flasht ?! einfach das erase/load kommando aus dem gdb.ini
file rausnehmen, oder hat der gdb da auch was gegen (soweit ich weiß
flasht der gdb mit dem load kommando den msp ja neu) ?!
dank und gruß
rene
noch mal eben eine frage :
muß ich bei eclipse das makefile von hand erstellen oder gibt es da ein
tool das das für mich übernimmt (immerhin wird ja auch nach
include-pfaden gefragt, und das nur für den indexer wäre ja etwas
übertrieben oder ?)
muß man da noch was spezielles einstellen oder sollte es "so" laufen
(wenn es denn ein solches feature gibt)
gruß
rene
Also. Den GDB-Server-Debugger kannst du eigentlich auch nehmen, bei mir
geht der sogar besser als der mspgcc-gdb oder wie der da heißt.
Protokoll am betsen mi2 benutzen.
Neustart ohne flashen geht entweder, wenn du dir eine Konsole und den
Verbose-Mode beim Debugger geben lässt, dann kannst du
monitor restart
c
eingeben und er is wieder am Anfang der Main()
oder eben das load rausnehmen, das klappt.
beenden des GDB-Servers mach ich einfach, indem ich das DOS-Fenster
schließe. Aber wie gesagt, ich hab den als external Tool im Eclipse, da
geht das dann per Stopp-Knopf.
Mit Managed Make Projekt musst du dich um kein Makefile kümmern, klappt
bei mir bestens. Automatic Build noch an, und er macht bei jedem
Speichern einen Compilerlauf.
Ma paar Bilder im Anhang.
Das stellt den gdp-proxy als Tool im Eclipse ein, lässt sich dann direkt
aus Eclipse starten und beenden.
Hallo Chris,
erst nochmal danke für deine Hints. Aber so richtig klappen will das
nicht.
Wenn ich den gdb-server debugger auswähle komme ich nur über das
mi-protokoll einen halben schritt weiter, bei mi2 sagt der mir sofort :
error creating session mit dem hinweis das der den mi2-interpreter nicht
finden kann.
bei mi fängt der an was zu laden, bricht aber nachher (wie im gestrigen
posting schon erwähnt mit "target selection failed" ab und liefert mit
das fehlerdetail das der ein über cygwin gemapptes file nicht finden
kann
/cygdrive/c/Programme/eclipse/C:\workspace\msp_test1/C:\workspace\msp_te
st1\msp_test1.elf:
(wie auch immer dieser filename zustande kommt ...)
noch eine kleine frage zum size-tool. ich kann den dialog nicht finden,
in dem ich die post-build schritte einstellen kann. läuft das vielleicht
nur mit managed code ? habe damit noch nichts gemacht (sollte ich aber
wohl besser :-))
gruß
rene
@chris
erstnocheinmal danke für den hinweis mit dem managed c project.
allerdings habe ich da noch das problem das wenn ich dateien in
unterverszeichnissen habe das das make sich dann auf die nase legt. muß
da noch was spezielles eingestellt werden ?
Hmm...mit Unterverzeichnissen hab ich so jetzt noch nicht ausprobiert,
aber kann das bei Gelegenheit ma testen.
Also wenn der den Befehlsinterpreter nicht findet, ist an deiner Install
was falsch würd ich sagen....bei mir klappt das auf Anhieb. Neuestes
Eclipse SDK und CDT haste drauf, ja?
also mit unterverzeichnissen scheint es noch ein problem zu geben. ich
kann die einzelnen dateien in den verzeichnissen compilieren, aber
gelinkt bekomme ich es nicht. und über ein build all schon gar nicht ...
:-(
der scheint sich da irgendwie zu verstrubbeln.
eclipse und cdt sind neu (gestern erst geladen).
Sooo...hab mal ausprobiert mit den Unterverzeichnissen. War gar nicht
ganz einfach. Bei mir klappt das nur mit einem managed-make Projekt
(mach ich eh immer) und dem "Internal Builder", zu aktivieren unter
Project -> Properties -> C/C++ Build -> Build Settings.
Da steht was von experimental, aber damit klappts.
Hab über New -> Source-Folder den Ordner erstellt und die Files da
reingelegt. Natürlich die '#include angepasst. Dann funktionierts.
Bild im Anhang.
Ohne den internen Builder erstellt der irgendwie in den
Unterverzeichnissen keine Dependency-Files (.d) und kann dann natürlich
nix linken.
Komisch....
