Program requires multiple restarts

[CatInc]

First Jan thank you for all your great work in helping with USB. We used the usbhido as a starting point for a VB6 application. It works well with one exception. When our device is first plugged into a USB port, the application program has to be restarted 3 times before reads work. After that, they work every time. Our device is found using FindTheHid. Then WriteReport is used to send a packet to the device. It has been verified that the device received the packet and transmitted back a response. ReadReport is used to attempt to receive the data from the device, Overlapping I/O is used. During the first two runs of the application, no data is detected, after that every time data is received. This was seen on Windows 8.1 and Windows 7. Any Ideas?
 
Any help would be appreciated.

[Jan Axelson]

I will admit that I haven't used the VB6 application in quite a while.

WriteFile completes without error?

ReadFile times out?

Do you see the data sent by the device on a hardware-based or software protocol analyzer?

[CatInc]

Hi Jan,

WriteFiel completes without error and ReadFile does timeout. The transmitted data from the device was tracked using a ICD3 on the device. The device is using a PIC.

[CatInc]

Hi Jan,

Have a lot more information and a partial solution. After being plugged into the USB, our device does not respond to the first OUT packet requesting information from the device. The VB6 application does the following
1.   FindTheHid which returns with valid handles
2.   WriteFile with the request
3.   ReadFile in attempt to get the response
4.   WaitForSingleObject which times out
5.   CancelIo(ReadHandle). which provides a message of “Overlapped I/O operation is in progress”
6.   CloseHandle(ReadHandle)
7.   CloseHandle((HIDHandle)
8.   Sets MyDeviceDetected = False
After a delay
FindTheHid is used again and this time it returns with the invalid handle of -1 for both the ReadHandle and HIDHandle. At this point WriteFile does not output anything on the USB. Previously the only way to recover was to restart the application program. Now steps 5, 6, and 7 above are not done and a second WriteFile is done. This time the device responds with its IN packet and all is good.

We still need to find out why the device is not responding to the first request. However, if for whatever reason the device does not respond, it would be nice if there was a clean way to recover by canceling the operation and releasing handles.

[Jan Axelson]

A common device firmware problem is to wait for an interrupt before arming the endpoint to accept the data and return ACK (assuming an OUT endpoint). You need to enable and arm the endpoint before anything happens on the endpoint. Microchip has lots of example USB firmware.

To prevent attempting to read data when the device hasn't received data (which I assume contains a request to send data in your application), add code that detects the failed write operation and retries.