This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Launchpad USB->UART Misery (TUSB3410VF)

Other Parts Discussed in Thread: TUSB3410

Hey all,

I've worked with the FT232RL (FTDI), the MCP2200, and the TUSB3410 usb to serial chips... and I gotta say, i've never had more problems with anything in my life than getting the TUSB3410 to work consistently. I'm attempting to write GUIs for the MSP430 launchpad and have just about given up because of the complete randomness and crappy performance of this chip. I'm developing on 4 different W7 machines and have tried multiple launchpads rev 1.4 and rev 1.5. All will randomly fail to program as well as randomly fail to send data consistently while the same GUI code will run on MCP2200, FT232RL for months. Hardest part is establishing the initial connection. Once that is done, it seems to work fine for awhile after that but never long term.

Regarding my hardware wiring.... its whatever the msp430 launchpad has by default. Regarding my software, here is an example of what I'm using to open the comm port in c++ and it doesn't seem to give me any complaints when I use it with the mcp2200 or the FT232RL.  Any help regarding this would be greatly appreciated!


static unsigned OpenSerial(wxString identifier, unsigned int bps) {
   int pstatus=0;

   if((com_port = CreateFile("\\\\.\\" +identifier, GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL))==0)
   {
      fflush(stdout);
      CloseHandle(com_port);
      wxMessageBox( _("Error: Could not create"),
      _("Comm Port"),wxOK | wxICON_INFORMATION  );
      
   }

   DCB dcb;
   ZeroMemory(&dcb, sizeof(dcb));
   dcb.DCBlength = sizeof(dcb);
   dcb.BaudRate = bps;
   dcb.ByteSize = 8;
   dcb.Parity = NOPARITY;
   dcb.fParity = FALSE;
   dcb.fDtrControl = DTR_CONTROL_DISABLE;
   dcb.fRtsControl = RTS_CONTROL_DISABLE;
   dcb.fBinary = TRUE;

   pstatus = SetCommState(com_port, &dcb);
   if( pstatus == 0 )
   {
      fflush(stdout);
      CloseHandle(com_port);
      wxMessageBox( _("Error: Could not set comm state"),
      _("Comm Port"),wxOK | wxICON_INFORMATION );
   }



   COMMTIMEOUTS to;
   to.ReadIntervalTimeout = 40;
   to.ReadTotalTimeoutConstant = 40;
   to.ReadTotalTimeoutMultiplier = 1;
   to.WriteTotalTimeoutMultiplier = 1;
   to.WriteTotalTimeoutConstant = 10;

   pstatus = SetCommTimeouts(com_port, &to);
   if( pstatus == 0 )
   {
      fflush(stdout);
      CloseHandle(com_port);
      wxMessageBox( _("Error: Could not set comm timeout"),
      _("Comm Port"),wxOK | wxICON_INFORMATION );
   }

   SetCommMask(com_port, 0);
   if( pstatus == 0 )
      {
         fflush(stdout);
         CloseHandle(com_port);
         wxMessageBox( _("Error: Could not set comm mask"),
         _("Comm Port"),wxOK | wxICON_INFORMATION );
      }


   return 0;

}

void CloseSerial() {
   CloseHandle(com_port);
}

unsigned int WriteSerial(void* data, unsigned int count) {
   unsigned int out; // Number of Bytes written
   WriteFile(com_port, data, count, &out, NULL);
   return out;
}

unsigned int ReadSerial(void* buf, unsigned int count) {
   unsigned int in; // Number of Bytes read
   ReadFile(com_port, buf, count, &in, NULL);
   return in;
}

  • Nathan Zimmerman said:
    I'm developing on 4 different W7 machines

    That's the problem. W7 isn't the friendliest OS for anything that requires more than standard drivers - or comes from Microsoft itself. The LauchPad driver is a bit specific as it provides JTAG functionality and serial applicaiton port functionality on the same USB device.
    The very most complaints about incompatibilities came from W7 or Vista users. Almost no problems with XP. The 'improved' driver model of W7 seems to have some driver compatibility problems on many machines.

    If you don't use the virtual COM port provided by Launchpad, but a separate serial connection, the problems should relax or even vanish. Well, this backchannel port is nice (and its limitation to 9600Bd is no problem with the software UART of the first G devices), but it is a hack still, simulating on the TUSB chip a second serial port (besides the one to the 1612 that does the JTAG).

    I agree that TI should do their best updating the drivers to reflect the latest changes in WIndows. However, Microsoft is usually quite reluctant to tell about internal changes, and about which internal 'comaptibel' changes might break existing 3rd party code. And if the developers happen to have a PC where it actually works, it is even more difficult to track the problem down. (in a big company like TI, the IT is usually all from the same source, so it works on all available machines or on none, apparently on all)

    I'm sorry that I don't have a solution for you, but maybe it gives you the necessary turn in the right direction to solve (or workaround) the problem by yourself.

     

**Attention** This is a public forum