• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 80 subscribers
  • Views 3412 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Windows CDC USB Driver Insights for MSP430 built-in USB

Jacob Preston
Intellectual 270 points
Other Parts Discussed in Thread: MSP430F5659
We are experiencing issues with Windows drivers concerning USB.  Specifically, we are using an MSP430F5659 with a USB CDC interface.
The issue we are experiencing depends on what driver we use.  If we use usbser.sys (the driver pointed to by the INF file generated by the descriptor tool) on Windows 7, unexpected physical disconnects aren't appropriately handled.  If an unexpected disconnect occurs without properly closing the COM port on the software side, we either have to reboot or disable and then enable the driver via Device Manager to get things working again.  Microsoft updated usbser.sys on Windows 10 and this issue has been resolved.  Unfortunately, we can't use that version of the driver on any other version of Windows.
On the other hand we have also tried a USB CDC driver from Thesycon.  If we use this driver and perform a software disconnect and then try to reconnect with a terminal program (i.e. Hyperterm, CoolTerm, etc.) while keeping the USB cable physically connected, we lose communications from the Host to the endpoint.  However, the endpoint can still send data to the host.  To fix this issue we have to physically disconnect and then reconnect the USB cable.  The Thesycon driver appropriately handled unexpected disconnects.
These issues have been tested on multiple machines running various versions of Windows from 7 to 10.  I don't expect TI to have a driver solution, but does anyone have any insight to fixing or at least working around these issues?    This has been tested with various versions of TI's USB API firmware with the same results.
  • 0
    Guru 316660 points

    Buggy drivers are buggy.

    Do you really need to emulate a COM port? If not, you could use plain vendor-specific bulk transfers, with the WinUSB driver. (But I don't know if that driver handles disconnections any better.)

  • 0 in reply to Clemens Ladisch
    Intellectual 270 points
    I see what you're saying with using WinUSB, but unfortunately we already have software written that knows how to communicate via COM ports. Moving to WinUSB would be more painful than just dealing with the bugs we've found with usbser.sys. I was just hoping someone out there knows of an alternative to usbser.sys other than Thesycon.
  • 0 in reply to Jacob Preston
    Guru 34483 points

    Jacob Preston said:
    I see what you're saying with using WinUSB, but unfortunately we already have software written that knows how to communicate via COM ports. Moving to WinUSB would be more painful than just dealing with the bugs we've found with usbser.sys. I was just hoping someone out there knows of an alternative to usbser.sys other than Thesycon.

    I done some usbser / winusb tests with msp430, regarding max transfer speed. Disconnecting / unplugging is not important for me, so never tested this.
  • 0
    Guru 316660 points
    What do you mean with a "software disconnect"? If it is normal closing of the port, this sounds like a bug in the driver, which Thesyscon may be willing to fix. If you're doing something else, it's possible that the API of Thesyscon's driver is not correctly used.
  • 0 in reply to Clemens Ladisch
    Intellectual 270 points

    Yes, I mean closing of the port via software.  This was a big issue with our software because our software doesn't idle with the port held open.  We're in talks with Thesycon now about the issue.  The problem we're seeing with usbser.sys is more manageable than the Thesycon one, but if Thesycon does offer a fix we'll continue to use that driver.

  • 0
    Intellectual 270 points
    We've found the issue with the Thesycon driver. In their INF file, they have a setting called ClearFeatureOnStartup that is enabled by default. For whatever reason, TI's USB stack isn't compliant with this setting, and it causes the software to become unresponsive with disconnecting from the COM port and reconnecting. We've used this same driver for other embedded USB applications and did not experience any issues. We now have a working driver that handles both closing/opening of the COM port while the cable remains connected and surprise disconnects of the cable.

**Attention** This is a public forum