Moin, nutze msp-gdbproxy und TI's MSP-FET430UIF schon seit Jahren mit einem MSP430F1611, mspgcc und Eclipse - klappt einwandfrei, d.h., der Controller wird über msp-gdbproxy sofort gefunden und kann geproggt werden. Nun habe ich den MSP430F5438 mit dem Olimex STK gestern bekommen und dieser Typ wird nicht erkannt. Lange im Forum gesucht und gegoogelt, Probleme scheinen bekannt wegen anderem JTAG-Protokoll. Gut, IAR Kickstart in der letzten Version geprüft, FET430UIF umgeflasht: geht, µC wird erkannt. Gleiches mit Programmiersoftware Lite FET-Pro430 von Elprotronic. Zurückgeflasht auf mspgcc-Toolchain, weil ich diese mit Ecplipse und dem 1611er weiterhin nutze möchte. Irgendeine Idee, wie ich beide Controller mit msp-gdbproxy ansprechen kann? Hat von euch jemand den 5438er mit dieser Kombination am Laufen? Ich würde gerne auf Code Composer oder IAR verzichten. Gruß Gunb
Wenn nach dem Firmware Updates des UIF der Controller ansprechbar ist, sollte es reichen die aktuelle msp430.dll und hil.dll aus IAR oder CCE ins bin Verzeichnis des msp430-gdbproxy zu kopieren, dann wird der da voraussichtlich auch erkannt.
Christian R. schrieb: > Wenn nach dem Firmware Updates des UIF der Controller ansprechbar ist, > sollte es reichen die aktuelle msp430.dll und hil.dll aus IAR oder CCE > ins bin Verzeichnis des msp430-gdbproxy zu kopieren, dann wird der da > voraussichtlich auch erkannt. Hallo, das hatte ich schon gemacht, nur will msp430-gdbproxy nicht mit den aktuellen msp430.dll und hil.dll zusammenarbeiten.
Vielleicht statt > msp430-gdbproxy > msp430.dll > hil.dll MSPDebug benutzen > "MSPDebug is a free debugger for use with MSP430 MCUs. It supports > FET430UIF, eZ430, RF2500, Launchpad and Olimex MSP-JTAG-TINY programmers." http://mspdebug.sourceforge.net/ Vorkompilierte Windows-Version: http://www.mikrocontroller.net/articles/MSPGCC#Einfaches_Assembler-Beispielprogramm
Gun B. schrieb: > das hatte ich schon gemacht, nur will msp430-gdbproxy nicht mit den > aktuellen msp430.dll und hil.dll zusammenarbeiten. Echt nicht? Hast du das vor oder nach dem Firmware Update probiert? Werd ich morgen auf Arbeit gleich mal testen. Zu Hause hab ich hier "nur" den Olimex.
Christian R. schrieb: > Echt nicht? Hast du das vor oder nach dem Firmware Update probiert? Werd > ich morgen auf Arbeit gleich mal testen. Zu Hause hab ich hier "nur" den > Olimex. Beides ausprobiert. Zuerst habe ich gestartet mit meiner Produktivumgebung für den MSP430F1611, die seit langem mit dem FET430UIF gut zusammenarbeitet. Seinerzeit das Firmware-Update durchgeführt und über msp-gdbproxy(USB) mit Eclipse verheiratet. Kompiliert wird mit mspgcc20081230. Vorgestern dann nach erfolglosen Versuchen mit obiger Umgebung die msp-gdbproxy der mspgcc4er-Version hier geladen, die hier im Tutorial empfohlen wird. Mit den bereits mitgelieferten msp430.dll und hil.dll ging's nicht. Also die latest version von TI geladen und im Verzeichnis ersetzt, sowohl mit dem "alten" msp-gdbproxy versucht als auch mit dem o.g. neuerem - geht nicht, bei letzterem kommt: debug: MSP430_Initialize() debug: MSP430_Configure() debug: MSP430_VCC(3000) debug: MSP430_Identify() error: msp430: Could not find device (or device not supported) (4) debug: MSP430_VCC(0) debug: MSP430_VCC(3000) debug: MSP430_Reset(ALL_RESETS) debug: MSP430_Close() Assertion failed: !msp430_status.is_open, file target_msp430.c, line 745 Neuer Versuch: IAR-Kickstart nimmt erst einmal ein Firmware-Update des Programmers vor, geht danach mit C-Spy, Controller wird erkannt und Programm kann geladen werden. Versuche ich dann wieder mit msp430-gdbproxy, dann meckert er, dass die Firmware nicht kompatibel ist und upgedated werden muss - gut, verständlich. Also zurück per msp430-gdbproxy-Update und .dll's vom IAR ins msp430-gdbproxy-Verzeichnis - geht nicht, weil sie dann eben nicht mehr mit der Firmware des Programmers übereinstimmen. Dann die dll's aus dem Lite FET-Pro430-Verzeichnis von Elprotronic ins gdbproxy kopiert - geht auch nicht, denn auch diese Software will vorher den Programmer updaten, bevor sie dann funktioniert. Heute habe ich von Rowley Associates mal die 30-Tage Eval geladen und probiert. Die macht ebenfalls ein Update des Programmers, funktioniert dann aber problemlos, erkennt den Controller prima. Logisch, dass der Programmer danach wieder nicht kompatibel mit msp430-gdbproxy ist. Durch Recherche im Netz habe ich einen älteren Beitrag gefunden, wo angemerkt wurde, dass das 5438er JTAG-Protokoll vom z.B. dem 1611er abweicht. Scheine nicht alleine mit dem Problem in Bezug auf den 54er-Typ und msp430-gdbproxy. Meine Frage an dich: nutzt du den 54er-MSP430, so dass du gleiche Voraussetzungen hättest? Gruß&Dank Gunb
Krapao schrieb: > Vielleicht statt >> msp430-gdbproxy >> msp430.dll >> hil.dll > > MSPDebug benutzen > >> "MSPDebug is a free debugger for use with MSP430 MCUs. It supports >> FET430UIF, eZ430, RF2500, Launchpad and Olimex MSP-JTAG-TINY programmers." > > http://mspdebug.sourceforge.net/ > > Vorkompilierte Windows-Version: > http://www.mikrocontroller.net/articles/MSPGCC#Ein... Oh, nach einer Alternative habe ich gesucht. Danke für deinen Hinweis, ich werde es heute noch ausprobieren. Mit welchem Controller setzt du das o.g. Tool ein? Gruß&Dank Gunb
Ich befasse mich seit kurzem mit dem Lauchpad (d.h. MSP430G2...) und bin dabei auf das MSPDebug gestossen. Laut MSPDebugs Versionshistory sollte dein MSP430F5438 aber auch von dem Tool unterstützt werden.
Gun B. schrieb: > Versuche ich dann wieder mit msp430-gdbproxy, dann meckert er, dass die > Firmware nicht kompatibel ist und upgedated werden muss - gut, > verständlich. > > Also zurück per msp430-gdbproxy-Update und .dll's vom IAR ins > msp430-gdbproxy-Verzeichnis - geht nicht, weil sie dann eben nicht mehr > mit der Firmware des Programmers übereinstimmen. Hm, das ist ja schon mal seltsam. Wenn du mit IAR das FW-Update eingespielt hast, müssten auch die DLLs dazu passen, denn die Firmware ist in der DLL drin. Du musst erst die DLLs reinkopieren und dann ein Update machen. Irgendwie geht das aus deinem Text genau andersrum hervor. Hast du mal die DLLs vom CCE ins bin Verzeichnis des alten msp430-gdbproxy kopiert und das FW-Update gleich mit dem Proxy gemacht? Irgendwas ist da bei dir komisch. Ich teste morgen mal, allerdings hab ich keine 54er Controller da. Bisher ging das immer problemlos mit den aktuellen DLLs.
Christian R. schrieb: > Wenn du mit IAR das FW-Update > eingespielt hast, müssten auch die DLLs dazu passen, denn die Firmware > ist in der DLL drin. Ja, das geht aber nur aus der IAR heraus (Version FET_R610.exe), dann ist der Programmer aber über msp-gdbproxy.exe nicht mehr ansprechbar. Christian R. schrieb: > Du musst erst die DLLs reinkopieren und dann ein > Update machen. Irgendwie geht das aus deinem Text genau andersrum > hervor. Na ja gut, das ist schon klar, ich habe natürlich erst die dll's ins Verzeichnis kopiert und dann msp-gdbrpoxy zum Updaten aufgerufen. Die Meldung mit msp430.dll und hil.dll aus dem IAR-Verzeichnis produziert dann folgende Meldungen (originale Kopien vom Screen): notice: msp430: TI USB FET update requested error: msp430: (null) (0) debug: MSP430_Initialize() error: msp430: The FET tool version does not match this program. Update requ ired. debug: MSP430_Initialize() error: msp430: The FET tool version does not match this program. Update requ ired. Ich habe fast den ganzen Freitag, Samstag und auch heute sämtliche dll's ausprobiert, auch die von elmicro, da sieht's nicht anders aus. Allerdings kann ich mit deren Software den MSP430F5428 ansprechen, nachdem ich deren Update gemacht habe, was automatisch vorgeschlagen wird, so lange man die Firmware des msp-gdbproxy-Updates noch drauf hat. Auch mit dem Crossworks wird der Controller erkannt, aber eben nur nach einem Update, wenn vorher die msp-gdbproxy-Firmware drauf war. Selbst wenn die Updates mit msp-gdbproxy erfolgreich geflasht werden können, bei all den dll's, die ich in den letzten zwei Tagen schon aus dem Netz gezogen habe, kann zwar mein 1611er angesprochen werden, nicht aber der 5438er Controller. Woher stammt denn dein msp-gdbproxy.exe? Wo finde ich die aktuellste Version? Ich habe bis jetzt die aus dem mspgcc20081230 - Paket genutzt und die aus dem Forum hier im Link: http://www.mikrocontroller.net/articles MSP430_eclipse_helios_mspgcc4_gdb-proxy Gruß Gunb
Ich hab auch nur den gdbproxy aus der Version vom 30.12.2008. Aber wie gesagt das ist so ziemlich egal, da die Firmware in der msp430.dll drin ist und der (bisher) mit allen neuen msp430.dll/hil.dll zusammen gearbeitet hat. Hab erst letztens die DLLs aus dem CCE 5.0.1 genommen und die Firmware damit aktualisiert. Damit ging dann noch alles. Der aktuellste Controller, den ich hab, ist allerdings der 2618. Soweit ich weiß, ist dem Proxy egal, welcher Chip dran hängt, denn bei den 2618 beispielsweise gings dann irgendwann mit den neuen TI DLLs einfach so. Vorher unknown device, nachher hat er den richtig erkannt.
Christian R. schrieb: > Soweit ich > weiß, ist dem Proxy egal, welcher Chip dran hängt, denn bei den 2618 > beispielsweise gings dann irgendwann mit den neuen TI DLLs einfach so. Tja, das wär' schön, aber 1000mal probiert und nicht erkannt, während der 1611er brav antwortet. So ganz unbekannt scheint das Problem nicht: http://forum.sparkfun.com/viewtopic.php?t=13349 und andere Seiten lassen sich ebenfalls mit dieser Meldung finden. Ich lade gerade den Code Composer, mal sehen, was der macht. Gruß Gunb
Gun B. schrieb: > So ganz unbekannt scheint das Problem nicht: > > http://forum.sparkfun.com/viewtopic.php?t=13349 Naja, da gehts ja um den Olimex. Der ist beim Update bissl eigen. Ich hab den ja auch, das update geht nur über die Prog-Software von Olimex. Die TI-Firmware passt dort auch nicht. Olimex liefert aber sehr regelmäßig die aktuellen DLLs, sodass man da auch wenig Probleme hat. Du hast ja aber den original-UIF, da passt die Firmware aus der msp430.dll und das Update geht auch über den gdbproxy.
Christian R. schrieb: > Du hast ja aber den original-UIF, da passt die Firmware aus der > msp430.dll und das Update geht auch über den gdbproxy. Ja, bis dato hatte ich keine Probleme, glaube aber, der Sache näher zu kommen: http://processors.wiki.ti.com/index.php/MSP_Debug_Stack und http://processors.wiki.ti.com/index.php/MSP430_JTAG_Interface_USB_Driver entscheidend ist wohl, was unter What's new in the MSP430.DLLv3 steht. Soeben habe ich die v2er Dlls ausprobiert, diese lassen über msp-gdbproxy noch ein Update zu, die aktuelle v3er-Dll, die in allen von mir oben genannten Applikationen (IAR, CCS, usw.) enthalten ist, funktioniert nicht mehr mit msp-gdbproxy, weder das Update, noch die eigentliche Funktion. Der Updateversuch mit der v3er ruft dann: error: msp430: The FET tool version does not match this program. hervor, mit der 2er geht's. Ich habe mir ebenfalls die Dll-Developer Pakete von TI für den MSP430 geladen, sowohl mit der alten als auch der neuen Dll. alte msp430.dll: 2.4.8.2 -> geht mit msp430-gdbproxy neue msp430.dll: 3.2.3.2 -> geht nicht mehr Entscheidend ist nun, wann du deinen CCS geladen hast, oder allgemeiner, welcher Version deine msp430.dll entspricht. Die ältere funktioniert zwar mit meinem 1611er, findet aber den 5438er nicht. Die neuere Dll läuft wiederum mit msp-gdbproxy nicht - was für ein Durcheinander. Nun gut, vielleicht für dich interessant, falls du Morgen mit FET430-UIF testen solltest. Verhindert vielleicht aneinander vorbeizureden und vielleicht die Lösung für zukünftige Probleme mit msp430-gdbproxy. Gruß Gunb
Krapao schrieb: > Ich befasse mich seit kurzem mit dem Lauchpad (d.h. MSP430G2...) und bin > dabei auf das MSPDebug gestossen. Laut MSPDebugs Versionshistory sollte > dein MSP430F5438 aber auch von dem Tool unterstützt werden. Habe dies heute ausprobiert. Beim Starten will das Teil immer eine Firmware haben, dich ich dann auch als hex-File im selben Ordner abgelegt habe. Wie rufst du mspdebug auf (Optionen)? Gruß Gunb
So, jetzt wirds klarer. ich hab eben mal geschaut. Ich hab tatsächlich noch die DLL in der Version 2.4.9.1 drauf. Mit der Version 3 scheints dann ja ohne Änderungen am gdbproxy wirklich nicht zu laufen. Da müsste man sich mal msp-debug anschauen. Ist ja aber auch besser, dass jetzt alles open-source ist. msp430-gdbproxy enthält ja jede Menge TI-Code.
Christian R. schrieb: > So, jetzt wirds klarer. ich hab eben mal geschaut. Ich hab tatsächlich > noch die DLL in der Version 2.4.9.1 drauf. Mit der Version 3 scheints > dann ja ohne Änderungen am gdbproxy wirklich nicht zu laufen. Da müsste > man sich mal msp-debug anschauen. Ist ja aber auch besser, dass jetzt > alles open-source ist. msp430-gdbproxy enthält ja jede Menge TI-Code. Ja, das war ein gutes Stück Arbeit am Wochenende, hat mich ganz schön geschlaucht :-) Aber gut, nun sind wir um eine Erfahrung reicher. mspdebug habe ich ebenfalls als Windows-Portierung angeschaut. Ich konnte sowohl den Treiber korrekt einrichten als auch eine erste Verbindung zum FET430-UIF machen, allerdings meckerte er noch. Werde ich mich heute noch mal mit beschäftigen. So langsam qualmt mir aber der Kopf vor lauter Treiberinstallationen, dll-Kopiererei aus allen möglichen Softwaren :-))) Danke dir für deine Antworten! Gruß und guten Start in die neue Woche Gunb
Ein weiterer Link zum Thema MSP430F5438 und msp-gdbproxy, was die älteren dll's angeht: http://develissimo.com/forum/topic/16061/?page=1#post-42555 Das Problem scheint also in Bezug auf diesen Controllertyp schon länger bekannt zu sein.
> Wie rufst du mspdebug auf (Optionen)? Bei dem Launchpad mit >> mspdebug rf2500 Dann erscheint die Kommandozeile des Tools und man kann weitere Kommandos angeben. rf2500 ist der Adaptertyp auf dem Launchpad. Mit den Optionen --fet-list und/oder --usb-list kannst du herausfinden, welche von MSPDebug erkannten Adapter angeschlossen sind und wie die anstelle des rf2500 anzusprechen sind. Man kann auch beim Aufruf schon Kommandos angeben z.B. um einen nicht interaktiven betrieb zu ermöglichen z.B. in einem Makefile für ein 'make program'. Dann gibt man die Kommandos einzeln auf der Kommandozeile an z.B. >> mspdebug rf2500 "prog a.out" exit Programmiert das angeschlossene Lauchpad mit dem Programm a.out und verlässt MSPDebug. Die "remote stub for gdb" bzw. "GDB client mode" Funktion von MSPDebug habe ich noch nicht benutzt. http://mspdebug.sourceforge.net/manual.html
Krapao schrieb: > Mit den Optionen --fet-list und/oder --usb-list kannst du herausfinden, > welche von MSPDebug erkannten Adapter angeschlossen sind und wie die > anstelle des rf2500 anzusprechen sind. Danke für die Kommandos. Nun gut, ich habe mspdebug nun mit zwei FET430-UIF mit alter und neuer Firmware ausprobiert, allerdings komme ich nicht bis zum Funktionieren durch: Searching for firmware for TI3410... - checking C:/MinGW/msys/1.0/local/lib//mspdebug/ti_3410.fw.ihex - checking ti_3410.fw.ihex Loaded 13765 byte firmware image (checksum = 0xb5) Starting download... ti3410: bulk write failed: Falscher Parameter. ti3410: firmware download failed Die Firmware habe ich für die aktuelle v3-Dll. Optionen --usb-list und --fet-list klappen, auch die Treiberinstallation ist ordnungsgemäß am Laufen. Ich kann auf keine ältere Dll zurückgreifen, sonst komme ich an den 5438er-Controller nicht dran. Denke langsam in Richtung Code Composer, der läuft. Zahlt eh die Firma. Wenn noch jemandem was einfällt, gerne interessiert. Ansonsten danke für's Mitmachen;-)
Thread beobachten
Seitenaufteilung abschaltenBitte 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.