MSP430: Debuggen von Funktionen im RAM

[Kamil P. (kamil)]

Hallo!
Ich habe mir eine Bibliothek für einen MSP430 geschrieben um Funktionen 
ins RAM zu laden und dort auszuführen. Klappt auch alles wunderbar. 
Allerdings kann ich Funktionen, die sich im RAM befinden nicht debuggen. 
Ich habe bereits folgendes probiert:

-Eclipse 3.3.1 mit CDT 3.0.2, mspgcc eclipse Plugin 0.0.2 und 
mspgcc-20060502
-> Debugger beendet die Auführung mit einem Fehler (leider vergessen) 
wenn man in eine Funktion springen will, die sich im RAM befindet. 
Überspringen der Funktion funktioniert problemlos

-msp430-insight-win32-20021222
Funktionen im RAM werden einfach übersprungen (wie Step Over anstatt 
Step Into)
Man kann allerdings in Funktionen im RAM springen wenn man den 
Assemblercode Schritt für Schritt ausführt. Es wird jedoch kein 
Assemblercode angezeigt (siehe angehängtes Bild). Sie läuft aber korrekt 
bei der Schritt für Schritt Ausführung.

-neueste Version von Eclipse 3.3.1.1 mit neuestem Zylin Embedded CDT und 
Zylin Plugin sowie neuestem mspgcc-20070216
->Ähnlich wie bei Insight kann man in die Funktion springen und sieht 
auch das gleiche. Man kann die Funktion allerdings nicht Schritt für 
Schritt durchlaufen - es passiert einfach gar nichts wenn man den 
nächsten Schritt ausführen will und nach einiger Zeit beendet sich der 
Debugger.

Ich habe gelesen, dass sich hier noch andere mit der Ausführung von Code 
im RAM beim MSP430 beschäftigt haben. Konnte jemand erfolgreich 
Funktionen im RAM debuggen (Schritt für Schritt Ausführung und dabei 
Assemblercode sehen)?

Gibt es eine Möglichkeit den msp430-gdb so zu konfigurieren, dass er 
dies unterstützt? Oder muss ich beim msp430-gcc einen Compiler Schalter 
speziellen wählen?

Gibt es eine Möglichkeit einen Breakpoint im RAM zu definieren? (Ich 
kenne ja die Adresse im RAM an der sich die Funktion befindet)

Welche weiteren Debugger gibt es, die ich ausprobieren könnte?

Ich beschäftige mich erst seit einem Monat mit dem MSP430, Eclipse, 
MSPGCC,... Vielelicht habe ich eine Kleinigkeit übersehen?

Wäre dankbar wenn mir jemand einen Tipp geben könnte!

Viele Dank!
Kamil

[Christian R. (supachris)]

Hab´s gerade mal probiert.
Also unter Eclipse kann ich zumindest im Disassembly debuggen. Irgendwie 
findet er aber den passenden Source-Code nicht. Müsste man das .elf File 
mal analysieren.
Einzelschritt geht, wenn man den Instruction Stepping Mode aktiviert. 
Siehe Bild.

[Christian R. (supachris)]

Ahso, Eclipse 3.3.1.1 mit CDT 4.0.1 und mspgcc von Mai 2006.

[Christian R. (supachris)]

Hab mal nachgeschaut. Im Elf-File ist der Quellcode der Ram-Funktion 
nicht enhalten. Warum auch immer.

[Kamil P. (kamil)]

Ich hab jetzt nochmal Eclipse 3.3.1 mit CDT 3.0.2, mspgcc eclipse Plugin 
0.0.2 und mspgcc-20060502 installiert und siehe da, es funktioniert. 
Ergebnis ist so wie auf dem Bild von dir (wie ich es haben wollte).
Davor hat sich der Debugger aufgehängt wenn ich mir die Disassambly 
anschauen wollte (Es steht "Pending..." im Fenster aber es tut sich 
nichts. Kommt jetzt auch ab und zu mal vor).

Gibt es eigentlich eine Möglichkeit sich den Stack komfortabel anzeigen 
zu lassen? Bisher öffne ich das Register Fenster, lese r1 ab und öffne 
dann das Memory Fenster an dieser Stelle.

Ich habe bei dieser Konfiguration (Eclipse 3.3.1 + mspgcc Plugin) noch 
ein Problem mit dem Debugger:
wenn ich das Memory Fenster öffne beendet sich der Debugger gelegentlich 
mit einem Stack Overflow (irgendeine java.StackOverflow Fehlermeldung).
Bei Eclipse 3.3.1.1 + Zylin Plugin ist dies noch nie passiert.

Welche Version von Eclipse und MSPGCC läuft eingentlich relativ stabil? 
Mit den zwei, die ich bisher ausprobiert habe bin ich nicht ganz 
zufrieden...

[Christian R. (supachris)]

Stabil? Gar keine. Die Versionen nach Mai 06 gehn überhaupt nicht 
gescheit mit dem USB-Debugger. Dieses Pending ist "normal", fast immer, 
wenn im Quelltext eine for-Schleife ist. Schrecklich.
Für den Stack hab ich auch keine Lösung, hatte da noch nie Probleme, 
deswegen nicht benötigt.

[Kamil P. (kamil)]

Christian R. wrote:
> Stabil? Gar keine. Die Versionen nach Mai 06 gehn überhaupt nicht
> gescheit mit dem USB-Debugger. Dieses Pending ist "normal", fast immer,
> wenn im Quelltext eine for-Schleife ist. Schrecklich.
> Für den Stack hab ich auch keine Lösung, hatte da noch nie Probleme,
> deswegen nicht benötigt.

Ich habe irgendwo gelesen, dass die neueste Version von Eclipse mit 
Zylin Plugin und einer selbst kompilierten Version von MSPGCC vom 
akutellem Quellcode mit GDB 6.0 anstatt GDB 5.1.1 und neuesten BinUtils 
stabil laufen soll.
Allerdings bin ich am Kompilieren von MSPGCC unter Cygwin gescheitert. 
Ich kenne mich nämlich gar nicht mit Linux & Cygwin aus. Ich glaube ich 
müsste eine ältere Version von GCC unter Cygwin installieren um MSPGCC 
kompilieren zu können. Wie das geht konnte ich bisher nicht rausfinden 
und habe aufgegeben... kompilieren dauert ewig, man bekommt sehr viele 
Informationen, die ich nicht verstehe und wie ich die Fehler beheben 
könnte hab ich nicht rausgefunden. Außerdem fehlt mir die Zeit um damit 
rumzuspielen...

Eclipse 3.3.1.1 mit Zylin Plugin und MSPGCC vom Februar 2007 läuft 
eigentlich ganz gut - bis auf debuggen von Funktionen im RAM.
Zumindest arbeite ich seit einer Woche einigermaßen zufrieden damit - 
jedenfalls besser als mit Eclipse 3.3.1, MSPGCC Plugin und MSPGCC vom 
Mai 2006 (Ich habe das Gefühl, dass dieses Plugin nicht ganz ausgereift 
ist)
Falls der Debugger von Eclipse nicht geht nehme ich die alte Version von 
MSP430-Insight aus dem Jahr 2002...

Ich benutze allerdings ein JTAG-Parallel-Kabel und auf dem Laptop habe 
ich einen USB-LPT Adapter um zu debuggen (ich hab keine funktionierende 
Parallel-Port Karte für einen ExpressCard Slot gefunden).

Vielen Dank für deine Antworten!
Kamil

[Christian R. (supachris)]

Ahso, ja mit dem LPT-Port gehn auch die neueren Versionen. Allerdings 
weder mit dem TI-USB Debugger noch mit dem Olimex Clone. Da kann man 
zwar flashen, aber Debuggen geht nicht, das ganze Ding schmiert dann ab.
Wenn man For-Schleifen vermeidet, geht die Version vom Mai 06 recht 
stabil, auch mit CDT.

Und meinen Kompiler kompilier ich nicht selber, soweit kommts noch ;)

[Kamil P. (kamil)]

Christian R. wrote:
> Und meinen Kompiler kompilier ich nicht selber, soweit kommts noch ;)

Ich hätte auch nie gedacht, dass ich sowas versuchen würde. Da ich aber 
die nächsten 5 Monate mit dem MSP430 arbeiten werde, wollte ich 
eigentlich eine gut funktionierende IDE mit Debugger haben.

Naja, ich werd's irgendwie überleben

[Rufus Τ. F. (rufus)]

> ... wollte ich eigentlich eine gut funktionierende IDE
> mit Debugger haben.

Sieh Dir mal Rowley Crossworks for MSP430 an ...

Bietet übrigens auch ein float-fähiges printf.

[Christian R. (supachris)]

Ich arbeite mit Eclipse + MSPGCC schon seit fast 2 Jahren beruflich, 
geht sehr gut. Meine Diplomarbeit ist auch darauf entstanden.