Hallo Zusammen, ich arbeite zur Zeit mit dem MSP430F5438 und verwende hierfür den MSP-FETU430IF JTAG Adapter. IDE besteht aus Code Composer Essentials ver 3.2.2.1.4, Compiler MSP430 Compiler v3.0. Das Teil macht aber nur Probleme, ständig bekomme ich die Meldung, das entweder der JTAG-Adapter nicht gefunden wird, oder kein MSP-device am JTAG-Adapter angeschlossen ist. Diese Fehler treten sowohl bei der original eval-Platine von TI (MSP-430FETU5x100) als auch bei einer Platinenselbstentwicklung auf. Hat jemand ähnliche Erfahrungen gemacht? Irgendwelche Kenntnisse über Softwareversion abhängige Probleme? Kann man den JTAG-Adapter updaten? Diese Problem ist nur zu lösen durch eine komplexe und höchst zufällige Kombination aus Spannungsversorgung an/aus, USB an/ab, usw...will sagen: absolut nicht reproduzierbar. Ich bin mir zu 99% sicher, dass es nicht an meiner Platineneigenentwicklung liegt, da bei mehreren Exemplaren dieselben Symptome auftreten, genau, wie bei der original TI-Platine, außerdem basiert meine Platine auf den Schaltplänen der TI-eval-Platine. Wäre dankbar, wenn ihr eure Erfahrungen / kenntnisse kundtut. Viele Grüße, mui
Hallo, > Das Teil macht aber nur Probleme, ständig bekomme ich die Meldung, das > entweder der JTAG-Adapter nicht gefunden wird, oder kein MSP-device am > JTAG-Adapter angeschlossen ist. Das kannte ich auch von meinem MSPFET430UIF. > Hat jemand ähnliche Erfahrungen gemacht? Irgendwelche Kenntnisse über > Softwareversion abhängige Probleme? Kann man den JTAG-Adapter updaten? Ja, msp430-gdbproxy kann das mit der Option "-update". Komischer Weise funktioniert msp430-gdbproxy bei mir nur unter Windows (dort habe ich auch das Update ausgeführt), unter Unix/Linux/BSD empfiehlt es sich den Fetproxy von xGoat (http://xgoat.com/wp/2009/03/25/fetproxy-an-open-source-replacement-for-msp430-gdbproxy/) zu verwenden. Der arbeitet bei mir immer wie gewünscht. hth, Iwan
hmm...hab etzt gerade msp430-gdbproxy.exe samt msp430.dll und hil.dll runtergeladen...wenn ich das so ausführe: msp430-dgbproxy.exe -update sagt er, dass er die option -update nicht kennt. bei --help ist das auch nicht aufgeführt...gibt es da was besonderes zu beachten? Grüße, mui
Naja, wenn du den aktuellen CCE herunter geladen hast, ist dort die aktulle msp430.dll dabei. In der DLL ist immer die aktuelle Firmware. Beim ersten Zugriff auf den UIF wird dieser aktualisiert, falls die Firmware in der DLL neuer ist als die auf dem FET. Wenn du das per msp430-gdbprox machst, wird eine alte Firmware drauf gebügelt, weil die msp430.dll vom MSPGCC älter ist. Falls du das probieren willst: "msp430-gdbprox msp430 --update-usb-fet" wäre der korrekte Befehl. Dann musst du aber auch die msp430.dll und die HIL.dll aus dem mspgcc/bin Verzeichnis in das TI Verzeichnis (C:\Programme\Texas Instruments\CC Essentials v3.1\DebugServer\drivers) kopieren, sonst wird der FET wieder aktualisiert, wenn du das nächste mal mit dem CCE was debuggen willst. Aber zu deiner Be(un)ruhigung: Das ist normal. Dieses Gefrickel ist einfach TI Standard. Ist bei den Spectrum Debuggern für den TMS320 auch nicht besser. Wenn man einmal die Reihenfolge mit Anstecken, abstecken, Strom an usw. raus hat, gehts. Da funktioniert selbst der Olimex Nachbau viel besser (und viel schneller).
Christian R. schrieb: > In der DLL ist immer die aktuelle Firmware. > Beim ersten Zugriff auf den UIF wird dieser aktualisiert, falls die > Firmware in der DLL neuer ist als die auf dem FET. Vielen Dank, das war mir nicht bekannt. Wieder etwas gelernt :-) > Aber zu deiner Be(un)ruhigung: Das ist normal. Dieses Gefrickel ist > einfach TI Standard. Das ist auch der Grund, warum ich in nächster Zeit wohl auf Toshiba um/einsteigen werde. Dort funktioniert alles relativ einfach. Die MSP-Freunde dürfen sich dann freuen, meine Sammlung werde ich wohl hier in /markt in den nächsten Monaten einstellen.
////////// Aber zu deiner Be(un)ruhigung: Das ist normal. Dieses Gefrickel ist einfach TI Standard. Ist bei den Spectrum Debuggern für den TMS320 auch nicht besser. Wenn man einmal die Reihenfolge mit Anstecken, abstecken, Strom an usw. raus hat, gehts. Da funktioniert selbst der Olimex Nachbau viel besser (und viel schneller). //////// na, das ist ja toll...ich hatte mich ja schon dran gewöhnt und irgendwann funktionierte der Kram ja auch, aber in letzter Zeit häuft sich das echt erheblich und ich hab langsam keinen Nerv mehr für so nen Mist...eigentlich auch ne Unverschämtheit das so ein teures Tool (im Vergleich z.B. zum AVR-Dragon) so schlecht funktioniert... naja, ich werde mal versuchen, eine aktuelle SW zu kriegen, in der Hoffnung dann in Ruhe arbeiten zu können. Vielen Dank an Alle, ich werde Bescheid geben, ob meine Bemühungen von Erfolg gekrönt sind :-)
Also gerade heute und gestern hat der mich auch geärgert. Auf einmal hat der Probleme, die F1611 auf dem UIF64 Demoboards zu programmieren. Stecke ich einen F2618 in die Fassung, klappts problemlos. Scheint aber am Board zu liegen, irgendwann gings dann wieder. Komisch. Generell klappts aber mit dem GCC viel stabiler, da hab ich solchen Zirkus nur, wenn wirklich mal was ist (keine Spannungsversorgung am target oder so). Ansonsten arbeitet der GDBProxy zuverlässig mit Eclipse. Und mit dem Olimex gehts noch besser. Der CCE Debugger ist zwar bedienerfreundlich, aber ziemlich wackelig.
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.