Hallo zusammen, mein Ziel ist es, mit dem MSP430 unter Linux zu arbeiten. Bezüglich Compiler und Linker bzw. postwork bin ich mit mspgcc, binutils und srecord bestens versorgt (Auch wenn es geraume Zeit gebraucht hat das Ganze ans Laufen zu bringen.) Als IDE bzw. Debugger sind eclipse bzw. gdb geplant. Jetzt fehlt mir allerdings noch ein Emulator. Das orginal FET von TI kommt aufgrund des Preises nicht in Frage, Spy-Bi-Wire haben die Derivate nicht und ein reiner Bootloader genügt nicht. Die Verbindung sollte wenn möglich über USB laufen. Beim Stöbern im Netz bin ich auf die folgenden Alternativen gestoßen: * usbprog http://shop.embedded-projects.net/product_info.php?info=p6_usbprog-v3-0--Adapter-vormontiert-.html (32 Euro zzgl. Versand) Finde ich persönlich ein sehr reizvolles Projekt!! * Olimex MSP430-JTAG-Tiny http://www.olimex.com/dev/msp-jtag-tiny.html http://shop.embedded-projects.net/product_info.php?info=p63_MSP430-USB-JTAG-Adapter--MSP430-JTAG-TINY-.html (65 Euro zzgl. Versand) Fragen: 1.) Soweit ich es verstanden habe unterstützt usbprog derzeit den MSP430 leider noch nicht, oder? 2.) Hat jemand von euch eines der Produkte unter Linux erfolgreich im Einsatz bzw. kann mir seine Erfahrungen mitteilen? 3.) Gibt es eine weitere Alternative, die ich übersehen habe? (In einem 'vernünftigen' Preissegment.) Besten Dank für eure Hilfe, odic
zu 1. Wird es auch in Zukunft sicherlich nicht, da das Protokoll Closed-Source ist und wohl von TI nicht freigegeben wird. Unter Linux wir einzig das ez430 (kann ja nur SBW) und der original USB-FET unterstützt. Kein Olimex. Ansonsten Parallel-Port, aber das ist ja schnarchlahm.
Danke für die Infos, auch wenn' schlechte sind. Das orginal FET ist mir zum Basteln einfach zu teuer. zu usbprog: Vielleicht sollte man die Hoffnung nicht zu früh aufgeben, immerhin hat es Olimex ja auch hinbekommen. (Ohne jetzt spekulieren zu wollen auf welchem Wege.) zu SBW: Ich besitze zwar einen eZ430, aber leider aus dem eZ430-RF2500, und der wird zumindest derzeit noch nicht unterstützt. Zwar genügt der F2274 als größter MSP430 mit SBW meinen Anforderungen völlig, aber leider sind die kleineren Derivate mit SBW nur schlecht zu bekommen. Ich dachte ursprünglich alles < F2274 hätte SBW, aber das war wohl ein Trugschluß. Wenn ich richtig informiert bin haben den nur 20x1, 20x2, 20x3, 21x2, 22x2 und 22x4, beim 2131 beispielsweise hatte ich Pech. Eine Lösung wäre evtl. noch die Entwicklung mit SBW auf dem F2274 zu betreiben, und dann "blind" zu portieren und mit BSL zu flashen. Wobei das sicherlich keinen Spaß macht. Es gibt einfach immer noch Punkte wo man mit Linux an die Grenzen stößt. Obwohl sich seit mehreren Jahren kein Windows besitzt und (zugegeben teilweise mit einem gewissen Mehraufwand) letztendlich noch fast alles gelößt bekommen habe. Grüße, odic PS: Bin weiterhin für jeden guten Tips offen.... ;-)
odic wrote: > Danke für die Infos, auch wenn' schlechte sind. Das orginal FET ist mir > zum Basteln einfach zu teuer. > > zu usbprog: > Vielleicht sollte man die Hoffnung nicht zu früh aufgeben, immerhin hat > es Olimex ja auch hinbekommen. (Ohne jetzt spekulieren zu wollen auf > welchem Wege.) Gegen NDA bekommt man die Spec als 3rd Party Hersteller ja. Viel Erfolg bei der Suche nach Lösungen. Vielleicht gibts ja auch bei Ebay mal ein original FET. Ansonsten halt LPT.
So, melde mich mal wieder zurück. Olimex Parallelport-Debugger ist gekauft und in Betrieb genommen. Funktioniert einwandfrei... auch wenn ich schonmal schneller gearbeitet habe. ;-) Eins ist mir allerdings noch nicht ganz klar. Soweit ich es verstehe kann ich das Target über den Parallelport mit versorgen (Pin 2). - Weiß jemand zufällig wie stark ich den belasten darf? Andererseits kann ich auch - vorausgesetzt ich interpretiere den Schaltplan richtig - die Ausgangsspannung des FET an VCC des Target angleichen (Pin 4). - Ist das eine Schutzmaßnahme oder verstehe ich hier was komplett falsch? - Sollte ich den Pin verwenden oder ist das bei einer Versorgung des Target mit ca. 3V nicht notwendig? Besten Dank für eure Antworten, odic
Normalerweise kannst du aus dem Par-Port keine Schaltung versorgen. Der MSP430 ohne Peripherie und mit niedrigen Takt geht aber. Allerdings kommen da nicht mehr als 2...3 mA raus, je nach Mainboard. Ist ja an den Datenleitungen angeschlossen, über diese Dioden. Über Pin 4 kannst du die VCC des Targets verwenden, um die Ausgangsspannung des JTAG-Interfaces an die Spannung des Targets anzugleichen. Wenn du den MSP z.B. mit 1,8V laufen hast oder sowas. Im Normalfall wird er mit 3,0V betrieben, genauso wie die HC244 Buffer auf dem Programmer.
Dann sollte VCC des MSP aber schon halbwegs stabil sein bzw. sich im Bereich um die 3V bewegen, sonst sind VCC + 0,3V schnell erreicht. Und das ist immerhin Maximum.... zumindest in der Theorie. Vielleicht sollte ich doch auf Nummer sicher gehen und den Pin immer anschließen, damit komm ich immer noch mit einem 8poligen Stecker aus. Apropos Stecker... gibt es eine Standardbelegung für eine 8polige JTAG-Verbindung?
Eben drum sollst du ja die VCC des MSP an den Debugger führen. Der Spannunsgolger-OPV dort drauf liefert dann für den HC244 die Spannung, die der MSP auch hat, somit wird der innerhalb VCC +0,3V betrieben. Wenn du den Pin weglässt, liefert der 3,0V, die über den hochohmigen Widerstand hinter dem Spannungswandler kommen. Standard-Belegung gibts nicht, nur für den 14poligen TI-Stecker.
Entschuldige, ich habe mich nicht klar genug ausgedrückt. Daß ich den Pin sinnvollerweise immer verwenden sollte war eine Feststellung, keine Frage. Hintergrund meiner Überlegungen ist der, daß ich für künftige Targets gerne mit einem 8poligen Stecker auskommen würde, da ich den 14poligen einfach zu klobig finde. Dieser Stecker sollte aber in verschiedenen Anwendungen immer gleich sein. Und ich kann im Moment noch nicht absehen, welche Versorgungsspannungen künftig zum Einsatz kommen. Aber da es inkl. Vcc genau 8 Signale sind, paßt das ja wunderbar. Jedenfalls vielen Dank für die ausführlichen Antworten bzw. die Bestätigung meiner Interpretation. Grüße, odic
Wir nehmen für unsere Projekte einen 10-poligen mit Rastermaß 1,27mm von Samtec. Reset wird nicht benötigt, also nur 4 JTAG plus VCC und auf der anderen Seite alles Masse. Somit ist jede 2. Leitung im Flachbandkabel Masse und die Kommunikation klappt zuverlässig.
Warum ist Reset nicht notwendig? Test bleibt doch auch noch, damit wären es ohne Reset immer noch 5 + VCC + GND, oder? Haben die Erfahrungen bei euch gezeigt, daß die Art der Abschirmung notwendig ist, oder ist das eine reine Vorsichtsmaßname?
Reset ist bei 4-Wire JTAG nicht nötig. Spy-bi-Wire, wo das Test nötig wäre haben wir bisher noch nicht eingesetzt. Wäre dann wahrscheinlich ein anderer Adapter nötig. Und ja, wir hatten manchmal Probleme mit fliegenden Leitungen.
Irgendwie kann ich gerade nicht ganz folgen. Setzt ihr nur Derivate ein, bei denen die JTAG Pins keine weitere Funktion haben, oder steuert ihr Test manuell?? Bleibt die Frage, wofür der Reset am FET vorhanden ist... Ich denke, zumindest bei dem Parallelport-FET muß ich mir über Abschirmung keine Gedanken machen. Bei der Geschwindigkeit kann ich die Elektronen zur Not immer noch selbst von einem Kabelende zum anderen tragen... ;-) Und fliegende Leitungen wird es auch nicht geben. Immerhin soll der Stecker so klein als möglich sein.
Wir haben bisher nur die größeren MSP430 mit extra JTAG pins eingesetzt, ja. Dieses gesharte konnte uns nie überzeugen. Dann lieber eine Nummer größer, und die JTAG Pins nur für JTAG.
Ok, das erklärt's natürlich. Nun, ich komm bislang noch mit den deutlich kleineren Derivaten aus. Danke für die Infos. Grüße, odic
Naja, da muss man immer sehr aufpassen, was man an die JTAG-Pins klemmt, und dann sind auch nicht alle Debug-Möglichkeiten machbar. Spy-Bi-Wire hatte ich mal an einem F2274 probiert, aber ging irgendwie überhaupt nicht. Bloß das geht ja mit deinem par-Port-Adapter eh nicht.
Falls jemand noch immer versucht, den Olimex MSP430-JTAG-ISO unter Linux zu betreiben, dann siehe angehängte Datei. Die Kommunikation ist ein ganzes Stück langsamer als unter Windoof, aber erträglich. Getestet ist das Ganze unter Ubuntu 9.04. Ob der -TINY auch geht weiss ich nicht, da nicht verfügbar.
Einfach genial! Ich kann die Funktion des Olimex MSP430-JTAG-ISO unter Ubuntu 9.04 bestätigen, bisher musste ich immer einen Windows PC haben, um den msp430-gdbproxy mit dem Olimex USB Debugger zu betreiben; damit ging es auch, aber die Lösung von Stefan ist eleganter. Und was die Geschwindigkeit angeht: ich sehe keine Unterschiede zu meiner vorigen Lösung (Windows 2000 VMWare-Player, Linux 9.04-Host, msp430gdbproxy über virtuelle vmnet-Schnittstelle freigegeben und Zugriff mit msp430-gdb in Eclipse) Vielen Dank!
Also den MSP430-JTAG-TINY bekomme ich damit nicht ans Laufen... wobei ich natürlich nicht ausschließen kann, dass es an mir liegt. ;-) Beste Grüße, Odic
Man kann übrigens auch unter Linux ein virtuelles XP im VMware-Server laufen lassen und darin die MSP-Entwicklungssoftware laufen lassen. ISPs, die über USB angeschlossen werden sind vom virtuellen XP ansprechbar.
Odic: Hast Du den Treiber laden können, d.h. bekommst Du ein /dev/ttyUSB0 (oder ähnlich) dazu? Der MSP430-JTAG-TINY hat mit Sicherheit eine andere Product-ID. Damit muss zumindest der Parameter bei modprobe anders sein. Wenn der -TINY dann auch noch eine andere Baudrate verwendet, musst Du die rausbekommen und in der Funktion FTD2XX_FT_W32_CreateFile den Teiler anpassen - oder FTD2XX_FT_SetDivisor implementieren. Letztere ist noch nicht implementiert, da ich nur den Anspruch "Funktion" und nicht "Vollständigkeit" hatte. Bei Bedarf helfe ich natürlich bei der Fehlersuche... Uhu: Klar funktioniert das mit Virtualisierung. Aber ich benutze doch kein Linux um darauf ein Windows zu emulieren. Von Details wie Speicher-, Rechenleistung- und damit auch Akkulaufzeitverlust mal ganz abgesehen :-)
Stefan schrieb: > Der MSP430-JTAG-TINY hat mit Sicherheit eine andere Product-ID. Damit > muss zumindest der Parameter bei modprobe anders sein. Wenn der -TINY > dann auch noch eine andere Baudrate verwendet, musst Du die rausbekommen > und in der Funktion FTD2XX_FT_W32_CreateFile den Teiler anpassen - oder > FTD2XX_FT_SetDivisor implementieren. Der JTAG-TINY benutzt den Silabs CP2102. Wahrscheinlich müsste man über den Treiber gehen. Aber es das klappt, bezweifle ich, denn unter Windows wird auch kein virtueller COM-Port erstellt. Die Kommunikation läuft offenbar direkt über die SiUSBXp.dll
Stefan schrieb: > Uhu: Klar funktioniert das mit Virtualisierung. Aber ich benutze doch > kein Linux um darauf ein Windows zu emulieren. Von Details wie > Speicher-, Rechenleistung- und damit auch Akkulaufzeitverlust mal ganz > abgesehen :-) Na ja, emuliert wird da garnix, das läuft in einer virtuellen Maschine und die Performance ist auf aktuellen Prozessoren nicht schlecht, aber für diese Notebook-Krücken ist das natürlich nichts, da hast du schon recht.
Christian: Das mit dem SiLabs wusste ich leider nicht. Wenn ich allerdings das Datenblatt überfliege, dann fallen mir gar keine Alternativen Modis als UART auf. Damit wird der Lösungsansatz wohl ebenso funktionieren. Nur das man eben einen Wrapper für die SiLabs .dll schreiben muss. (Den -ISO sieht man im Windows ja ebenfalls nicht als COM-Port. Obiges Paket stellt auch nur die dll für den FDTD bereit.) Uhu: Ja, ich bin bei meiner Wortwahl manchmal etwas nachlässig :-)
Hallo Stefan, die andere device-id war klar. Meine Vorgehensweise: modprobe ftdi_sio vendor=0x15ba product=0x0002 Olimex JTAG-TINY einstecken dmesg: ftdi_sio: v1.4.3:USB FTDI Serial Converters Driver usb 1-2.4: new full speed USB device using ehci_hcd and address 42 usb 1-2.4: configuration #1 chosen from 1 choice ftdi_sio 1-2.4:1.0: FTDI USB Serial Device converter detected ftdi_sio: Detected SIO usb 1-2.4: FTDI USB Serial Device converter now attached to ttyUSB0 ftdi_sio: ftdi_set_termios FAILED to set databits/stopbits/parity ftdi_sio: ftdi_set_termios urb failed to set baudrate ftdi_sio: urb failed to clear flow control ftdi_sio: update_mctrl Error from MODEM_CTRL urb: DTR HIGH, RTS HIGH hub 1-2:1.0: port 4 disabled by hub (EMI?), re-enabling... usb 1-2.4: USB disconnect, address 42 ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0 ftdi_sio 1-2.4:1.0: device disconnected hub 1-2:1.0: Cannot enable port 4. Maybe the USB cable is bad? hub 1-2:1.0: Cannot enable port 4. Maybe the USB cable is bad? hub 1-2:1.0: Cannot enable port 4. Maybe the USB cable is bad? hub 1-2:1.0: Cannot enable port 4. Maybe the USB cable is bad? hub 1-2:1.0: unable to enumerate USB device on port 4 Weiter habe ich mich aus Zeitmangel bislang nicht damit beschäftigt... Beste Grüße, odic
Hi Odic, Christian sagte, dass im -TINY ein SiLabs steckt. Im -ISO ist es ein FTDI. D.h. der Wrapper funktioniert nicht so einfach. Im schlimmsten Fall müsste man also die entsprechende SiLabs dll nachbauen. Aber mal angenommen das Protokoll ist das gleiche wie beim -ISO, dann kann man den SiLabs Treiber laden "modprobe cp210x product=0x0002 vendor=0x15ba" (siehe http://www.etheus.net/CP210x_Linux_Driver). In FTD2XX_FT_W32_CreateFile muss man dann sicher die Baudrate anpassen. Wer will mit Oszi nachmessen?
Hallo Stefan, das Kernelmodul gibt's bei mir nicht, da habe ich beim backen wohl was vergessen. Sobald ich Zeit habe, werde ich das nachholen... Bezgl. Baudrate: Zwar nicht schön, müsste aber eigenlich klappen - einfach mal Standard-Baudraten durchprobieren, bis es funktioniert. Beste Grüße, Odic
Hallo, hat vielleicht schon jemand den msp430 JTAG-TINY unter Ubuntu zum "Sprechen" bekommen? Ich hab dieses Teil und auch den JTAG über die Parallele Schnittstelle - beide wollen zur Zeit nicht laufen. Wäre für jegliche Hilfe sehr dankbar. Helmut
Hallo an alle, Es steckt eindeutig ein SiLabs darin. Ich poste euch meine Ausgabe von lsusb: --------------------------------------- Bus 003 Device 004: ID 15ba:0002 Olimex Ltd. Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x15ba Olimex Ltd. idProduct 0x0002 bcdDevice 1.00 iManufacturer 1 Silicon Labs iProduct 2 OLIMEX MSP430 JTAG TINY iSerial 3 030006B4 bNumConfigurations 1 Auch ich versuche derzeit den MSP430-JTAG-TINY unter Ubuntu zu betreiben. Ich hoffe wir können die Vendor Specific Class zum laufen bringen. Den ganzen Output von lsusb findet ihr im Anhang. Beste Grüße Raphael
odic schrieb: > Danke für die Infos, auch wenn' schlechte sind. Das orginal FET ist mir > zum Basteln einfach zu teuer. ébay #270422621040 ? fchk
Ich kann bestätigen, dass der MSP430-JTAG-TINY von Olimex unter Ubuntu NICHT lauffähig ist. Das Problem ist, dass das /dev/ttyUSB0 nicht eingebunden wurde. VendorID und ProductID werden korrekt angezeigt. Treiber für USB<->RS232 Wandler für cp2102 existieren auch seit Kernel > 2.6.20. Zwingt man nun das System per /etc/moduls-Eintrag: usbserial vendor=0x15ba product=0x0002 den usbserial Treiber zu verwenden so wird das Device beim Anstecken an USB erkannt und in /dev/ttyUSB0 eingebunden. Eine Verbindung per msp430-gdbproxy lässt sich jedoch trotzdem nicht aufbauen. msp430-gdbproxy msp430 /dev/ttyUSB0 Fehlermeldung: debug: MSP430_Initialize() error: msp430: Could not initialize device interface (1) Also rate ich entweder zum MSP430-JTAG-ISO von Olimex oder zum original MSP-FET430UIF von Texas Instruments. Viel Erfolg Raphael
Hat das schonmal jemand aus einem virtuellen XP unter Ubuntu ausprobiert?
Uhu: Ja - zumindest mit Win2k (siehe oben, Beitrag von Tino) Raphael: Wenn Du schon die serielle aktiviert hast, könntest Du ja mal mein oberes Paket für den -ISO probieren. Möglicherweise reicht es, einfach nur die Baudrate anzupassen. Im schlimmsten Fall muss man eben für die SiUSBXp.dll auch noch einen Wrapper schreiben... Da ich keinen -TINY zur Verfügung habe, kann ich da leider nicht so recht weiterhelfen.
Hallo Stefan, leider habe auch ich den Olimex-MSP430-JTAG-TINY nicht mehr zum Testen zur Verfügung. Leider scheint es so, als würde der Erfolg hierbei noch eine Weile auf sich warten lassen. schönen Sonntag wünscht Euch Raphael
Hallo, also das Protokoll bei -TINY und -ISO ist offenbar das gleiche: Ich habe mal einen Wrapper für die SiUSBXp.dll geschrieben und die Baudrate an meinen -ISO angepasst. Funktioniert soweit... Im angehängten Paket habe ich das mal zusammengepackt und die Baudrate auf den -TINY umgestellt. Probieren kann ich es ja leider nicht, aber vielleicht gehts ja auf Anhieb... Falls man den Treiber zum cp210x anders laden muss als in der README beschrieben, dann bitte auch eine kurze Rückmeldung geben. Stefan
Achso, folgendes habe ich noch vergessen: Laut Raphael meldet sich der -TINY mit "OLIMEX MSP430 JTAG TINY" bei lsusb. Ich muss dem gdbproxy aber "MSP430 JTAG Tiny " zurückgeben, damit es weitergeht. (Man beachte Gross/Kleinschreibung bei Tiny und das Leerzeichen am Ende.) Vielleicht kann jemand diesen Widerspruch aufklären.
@Stefan Ach so schade! Hätte ich gerne getestet -> Leider hab ich keinen TINY mehr hier. Vielleicht in den nächsten Monaten wieder. Bis dahin hoffe ich, dass einige andere Tester kommen. Danke für den Wrapper Stefan! liebe Grüße Raphael
Leider waren alle meine Versuche mit dem Olimex MSP-JTAG-TINY unter Linux erfolglos. Das CP210x Kernelmodul (aus Kernel 2.6.37.2) ist geladen und erkennt den Adapter:
1 | usb 1-3.4: new full speed USB device using ehci_hcd and address 18 |
2 | USB Serial support registered for cp210x |
3 | cp210x 1-3.4:1.0: cp210x converter detected |
4 | usb 1-3.4: reset full speed USB device using ehci_hcd and address 18 |
5 | usb 1-3.4: cp210x converter now attached to ttyUSB0 |
6 | usbcore: registered new interface driver cp210x |
7 | cp210x: v0.09:Silicon Labs CP210x RS232 serial adaptor driver |
Ergebnis mit WINE:
1 | $ wine msp430-gdbproxy.exe msp430 TIUSB |
2 | |
3 | Remote proxy for GDB, v0.7.1, Copyright (C) 1999 Quality Quorum Inc. |
4 | MSP430 adaption Copyright (C) 2002 Chris Liechti and Steve Underwood |
5 | |
6 | GDBproxy comes with ABSOLUTELY NO WARRANTY; for details |
7 | use `--warranty' option. This is Open Source software. You are |
8 | welcome to redistribute it under certain conditions. Use the |
9 | '--copying' option for details. |
10 | |
11 | debug: MSP430_Initialize() |
12 | error: msp430: Could not initialize device interface (1) |
Ergebnis nativ:
1 | $ msp430-gdbproxy msp430 /dev/ttyUSB0 |
2 | |
3 | Remote proxy for GDB, v0.7.1, Copyright (C) 1999 Quality Quorum Inc. |
4 | MSP430 adaption Copyright (C) 2002 Chris Liechti and Steve Underwood |
5 | |
6 | GDBproxy comes with ABSOLUTELY NO WARRANTY; for details |
7 | use `--warranty' option. This is Open Source software. You are |
8 | welcome to redistribute it under certain conditions. Use the |
9 | '--copying' option for details. |
10 | |
11 | debug: MSP430_Initialize() |
12 | error: msp430: Could not communicate with FET (35) |
Gibt's noch weitere Vorschläge? Danke.
Eduard Steinberg schrieb: > error: msp430: Could not communicate with FET (35)[/code] > Gibt's noch weitere Vorschläge? Danke. Darfst du auf ttyUSB0 zugreifen, als user? ls -l /dev/ttyUSB0 ggf. ändern, chmod o+rw /dev/ttyUSB0 oder Gruppenzugehörigkeit ansehen, wäre der erste Gedanke.
Das wird weder per Wine noch nativ mit dem msp430-gdbproxy klappen. Du brauchst unter Linux den mspdebug http://mspdebug.sourceforge.net/ für den JTAG TINY.
Tipp am Rande: Ich hab das Launchpad (<5€) erfolgreich an meinem (K)Ubuntu System im Einsatz (gibt im I-Net Erklärungen wie man den msp-gdb da ranklotzt....). Das ttyUSB Problem hab ich (vlt. etwas radikal) damit umgangen, dass ich das terminal-proggi als root laufenlass und die Adresse manuel eintrag...
Christian R. schrieb: > Das wird weder per Wine noch nativ mit dem msp430-gdbproxy klappen. Du > brauchst unter Linux den mspdebug http://mspdebug.sourceforge.net/ für > den JTAG TINY. Perfekt. Damit funktioniert es einwandfrei. Danke!
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.