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.
