On Sep 28, 2010, at 9:57 AM, JMGross wrote: > Nobody ever told how it really works, only that it is no real UART > (neither hardware nor software) on the launchpad side. It is mainly > used to provide a console while inside a debugging session of the > IAR debugger.
From what I've read and discovered (may not be 100% accurate): On the target MSP430 itself, the "serial port" is implemented as a timer-based software-generated "standard" async serial signal (at whatever voltage the board is running at.) In the "programming circuitry", the backchannel is implemented by a software-generated UART in the TUSB3410 (which has its own 8051 cpu.) The USB side is supposed to show up as two devices on your computer. One is a user-mode-writable "HID" device that is used for the JTAG/ Spybiwire/debug connection (and is supported by mspdebug and probably gdbproxy.) The other is a "Communications Device Class" (CDC) device that is supposed to show up as a Com port on the host computer and talk to the "serial port" of the target device, so that random host applications can talk to the target apps using standard serial port semantics and coding. So in theory, when you plug in a LaunchPad, you get the debug interface that only TI tools, MSPDEBUG, and similar can talk to and you get a standard COM port that applications can easily talk to. This is the same device/model/firmware as the EZ430-RF2500 and the Chronos Watch, I believe... Unfortunately, the code in the TUSB3410 that implements the CDC-based com port apparently does so in a way that is not what some operating systems are expecting. It works on windows, but is flakey (or at least version dependent) on linux and doesn't seem to work on Macs at all. A working CDC-based device I have on my Mac shows up as having a "Communications Control" interface AND a "Communications Data" interface. The (non-working) LaunchPad shows up has only having a "Communications Control" interface, with a couple of extra "bulk data" endpoints that are presumably for data. My understanding is that the "control" interface would normally be for dialing and, well, CONTROL things, and actual data transfer would occur over the separate "data" interface. The TI equipment seems to expect to have data transfer over the separate endpoints of the control interface. (And about there my understanding of USB stops...) There are a couple of consequences of all this. 1) An "improved TUSB3410 driver" isn't going to help, because the TSUB3410 on the LaunchPad is not running standard TUS3410 "serial" firmware. 2) Likewise, patching a TUSB3410 driver that only supports the serial port won't help. 3) It's not expecting to NEED any special host side drivers; just standard HID and CDC drivers. Unfortunately, it's buggy and doesn't work on Mac/Linux. 4) As far as I know, none of the internal info on how it is supposed to work is publish. My occasional jabs at TI "are you going to open up the USB/JTAG software" gets only silence in response. 5) The kernel-side host USB drivers are significantly different between linux and Mac. Getting one to work won't help the other. Much. BillW ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Mspgcc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mspgcc-users
