lpcware

Possible issue with USBD when multiple connects?

Discussion created by lpcware Employee on Jun 15, 2016
Latest reply on Jun 15, 2016 by lpcware
Content originally posted in LPCWare by simonhaines on Tue Jan 06 00:35:45 MST 2015
I'm using the USB device ROM stack from the lpc_chip_43xx project to enable CDC communication from my board to Windows (using usbser.sys) based on the VCOM examples.

I am able to connect to my board and send/receive data OK. However, after disconnecting and reconnecting the device (which is separately powered and so remains running during disconnect), subsequent calls to USBD_API->hw->WriteEP do not call the VCOM_bulk_in_hdlr code to notify that a write has been completed. After a reconnect, the first call to USBD_API->hw->WriteEP correctly returns the number of bytes in the message, but because no subsequent call to the VCOM_bulk_in_hdlr is made, the VCOM_TX_BUSY flag is never cleared.

This only occurs after a disconnect and reconnect (it works as expected during the first session), and must be reset by uninstalling the driver under Windows, and removing and re-inserting the device (which somehow seems to reset the USB stack on my device).

Is this an issue with the USBD stack, which may not accommodate separately-powered devices? Or am I missing something? Here is how I reproduce my problem:
[list]
  [*] Connect device to Windows, it is recognised and a COM port is created
  [*] Open the COM port, the device's VCOM_SetLineCode function is called (8 times)
  [*] Use a terminal program to send/receive data OK
  [*] Disconnect the device by removing the cable, the device remains powered
  [*] Connect the device by inserting the cable, it is recognised and a COM port is created
  [*] Open the COM port, as above the device's VCOM_SetLineCode function is called
  [*] Use a terminal program to send data: the data is received OK and the device echoes it back by calling USBD_API->hw->WriteEP which returns the correct number of bytes, but no subsequent call to VCOM_bulk_in_hdlr is made, so that the VCOM_TX_BUSY flag is never cleared
  [*] To recover, uninstall the driver under Windows (without deleting the driver software), disconnect and re-connect the device
[/list]

Many thanks for any suggestions.

Outcomes