Ein TI Launchpad MSP-EXP430G2 Rev. 1.5 an Win7 32 bit macht große Probleme beim Zugriff auf den virtuellen COM-Port (VCP/USB-CDC), wenn der Mikrocontroller stets Daten sendet. Selbst HTerm steigt aus und kommt nicht hinterher, den Buffer auszulesen bzw. verliert die Verbindung. Manchmal steigt auch der "Emulator" aus: Error initializing emulator: Could not find MSP-FET430UIF on specified COM port Es hilft dann eigentlich nur Neustart von Code Composer Studio (dadurch wird wohl die MSP430.dll neu geladen). http://processors.wiki.ti.com/index.php/MSP_Debug_Stack Die (jetzt) aktuelle gibt es hier: http://software-dl.ti.com/msp430/msp430_public_sw/mcu/msp430/DLLv2/3_04_002_007/exports/msp430.dll_developer_package_rev_3.04.002.007.zip Die installierte DLL findet sich in X:\Program Files\ti\ccsv5\ccs_base\DebugServer\drivers Die habe ich ersetzt. Das Verhalten bleibt aber ähnlich: Stop Debugger -> CPU läuft weiter und sendet HTerm disconnect ... Weilchen warten .. HTerm connect -> not responding ... mit Glück lädt HTerm dann den buffer, sagt aber es kann nicht verbinden. Dann connect -> Daten laufen. Wenn man im Debugger pausiert und dann stoppt, gibt es keine Probleme (weil nichts mehr gesendet wird).. Gibt's evtl. einen echten "fix"?
Hallo Info, schon mal Baudrate runtergesetzt ? z.B. 2400 mfg Erik
Info schrieb: > Gibt's evtl. einen echten "fix"? Vermutlich musst Du das hier vermeiden: > wenn der Mikrocontroller stets Daten sendet. Das dürfte insbesondere rund um den Verbindungsaufbau störend sein. In Deinem Programm könntest Du dafür sorgen, daß Dein µC entweder nach Start 'ne Zeitlang die Klappe hält, oder aber erst anfängt, zu senden, nachdem ihm das durch ein entsprechendes Kommando erlaubt wurde. Ich würde diese Schnittstelle als reine Debugkrücke betrachten und so zurückhaltend wie möglich nutzen. Da ich ein vergleichbares Phänomen auch beim Experimentieren auf dem Mac festgestellt habe, vermute ich, daß das eigentliche Problem im auf dem Launchpad integrierten (abgespeckten) MSP-FET430UIF liegen könnte. Es wäre interessant, das mit einem der neueren Launchpads auszuprobieren, deren integriertes SBW-Interface nicht mehr aus einem MSP430F1612 und einem TUSB3410 (einer USB-Seriell-Brigde, siehe http://www.ti.com/product/tusb3410) besteht. Hier wird stattdessen ein MSP430F5528 verwendet, der von sich aus USB unterstützt und etwas leistungsfähiger als der --übrigens übertaktete!-- 'F1612 ist. Das sind beispielsweise MSP-EXP430FR4133, MSP-EXP430FR5969 oder MSP-EXP430F5529LP. Ebenso dürfte der Nachfolger des MSP-FET430UIF interessant sein, der jetzt nur noch MSP-FET genannt wird. Der verwendet einen MSP430F6638 und ein FPGA (A3PN125-VQG100, siehe http://www.microsemi.com/document-portal/doc_download/130705-proasic3-nano-flash-fpgas-datasheet)
:
Bearbeitet durch User
Danke für die Bestätigung. Hier ein evtl. verwandtes Problem: http://e2e.ti.com/support/microcontrollers/msp430/f/166/t/230616 Aber - "Gefahr erkannt, Gefahr gebannt" oder so ähnlich. http://www.ti.com/tool/msp-fet - US$ 115 Bei Hardwarefehlern gibt es also evtl. die Chance auf ein Workaround per Software-Update.. "Includes Backchannel UART for bi-directional communication between the MSP430 and a PC - This could enable simulation of inputs from sensors as well as logging of debug data while an application is running" Habe jetzt nicht Angaben zu den unterstützden Baudrates gesucht.
Das Problem haben eigentlich alle Seriell-USB-Wandler. Was hilft, ist ein Terminalprogramm das die (emulierte) serielle wirklich zuruecksetzt. TeratermPro hat sich da bei mir bewaehrt.
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.