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.htmlhttp://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.
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
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
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)
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!
