Possible issue with USBD when multiple connects?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Possible issue with USBD when multiple connects?

829 Views
lpcware
NXP Employee
NXP Employee
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.
Labels (1)
0 Kudos
3 Replies

756 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by simonhaines on Sun Feb 22 22:23:28 MST 2015
The correct resolution to this issue is to abandon using VCOM with the Windows usbser.sys driver, and instead implement a WCID device (WinUSB). Better for all concerned. See the wiki for the 'libwdi' (pbatard) project on GitHub for invaluable information.
0 Kudos

756 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by simonhaines on Wed Jan 07 01:33:06 MST 2015
Thanks Tsuneo,

Yes I've been closing the COM port on the terminal program (RealTerm). I don't have a hardware analyzer, but using packet capture (Usblyzer) I've been able to determine that a write on the CDC_IN endpoint from device to host does not arrive at the USB hub on the host, after a disconnect/reconnect event.

As it works OK under Linux for multiple disconnects/reconnects, I believe there is a subtle issue with the way the CDC part of the USBD stack interacts with the Windows usbser.sys driver when the device is separately powered. I think there is some state being retained, or some specific configuration sequence not occurring, when the device disconnects but doesn't power down, then reconnects to usbser.sys. I've tried calling USBD_API->hw->ResetEP(pVcom->hUsb, USB_CDC_IN_EP) from the USBD_API_INIT_PARAM_T.USB_Configure_Event callback, which is reliably called on cable insertion, but this has no effect.

I'm not sure what else I can try. I'd like to know if the problem is reproducible on other Windows systems (I'm using 8.1). The 'usbd_rom_cdc_vcom' example from the LPCOpen package (http://www.lpcware.com/content/nxpfile/lpcopen-platform) should be enough to test with Windows drivers from here: http://www.lpcware.com/content/blog/usb-cdcacm-drivers-windows

Further suggestions much appreciated.
0 Kudos

756 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Tsuneo on Tue Jan 06 03:14:54 MST 2015

Quote:
Disconnect the device by removing the cable, the device remains powered



Did you close the COM port on the PC "terminal program", before the USB cable is pulled off?

It may be a problem on the host side, when the "terminal program" still grabs the COM port while disconnection / reconnection.

If you would have a hardware analyzer, you could tell which one has the problem, host or device, at once ..

Tsuneo
0 Kudos