PORTS Forum
Ports and Interfaces => USB => Topic started by: tk on November 13, 2014, 10:25:16 pm
-
In our system, we get data messages from a HID device, which is implemented as a vendor defined one, through Windows. The way to access the device is very orthodox I think: execute ReadFile in the asynchronous mode, wait its completion by WaitForXXX, and then get input data by GetOverlappedResult when the ReadFile process completes.
We have been using the system for more than ten years since the age of Win2K. But recently, maybe since we have replaced the host to Win7, we have been experiencing a trouble: The GetOverlappedResult fails and GetLastError executed just after the failure returns ERROR_DEVICE_NOT_CONNECTED(=0x0000048F). We traced the USB traffic and found that SOFs and IN tokens were sent continuously even when the failure occurred. We don't have any ideas why Windows determines that the USB connection is disconnected and returns the error code in the situation like that.
We have many systems. But the trouble is not caused in every one. Almost all of them don't cause that.
I'm very pleased if someone who has the same experience gives me some advice or hint to approach its root cause.
Thanks in advance.
-
If the IN tokens stop on the failure (not clear from your description whether this is true), check to be sure the endpoint is NAKing or ACKing every IN token packet before the failure.
If the device re-enumerates after the failure, there was a problem of some sort that caused the host to re-establish communications.
-
This suggestion is more on the mundane side - but, have you considered trying a powered USB hub just to see if the device is having a power problem?
-
The USB traffic showed that the host sent IN tokens to the endpoint, which is assigned as Interrupt-IN, and the endpoint responded to each token with NAK when the failure occurred. Communication was continuing at that time. It showed neither any occurence of disconnection nor any re-enumeration.
Since the endpoint was responding to the tokens, I think it's difficult for us to think that power failure or something like that was caused with the device.
-
If the device is still connected and communicating, the error message is wrong.
Does the device send the data?
If yes, and if the application ignores the error, does the GetOverlappedResult eventually succeed?
-
Yes, it does. The traffic shows that the device sent data in return to some USB's standard request. Adding to that, I can find some data sent via Interrupt-IN transfer.
If my application ignores the error, from where and how can it retry the procedure? The current version of the application is designed to consider the failure a fatal one.
-
In the application's error handling, ignore the error except for setting a flag to inform the application that the error occurred. Then check the flag on completing the transfer. This is only for testing as it looks like something is going wrong, you just don't know what yet.
-
I have gotten new facts:
- The device disconnection is caused not only in Win7, but also in WinXP.
- My application starts the reading process just after completing to open the communications and getting a handle for the device.
- The trouble occurs when a device that has not been plugged into the host is installed into the host and the application gets a handle while the message, which means some brand-new device is found, by Windows is still shown in the screen. The application can get a handle, and then it can receive some Interrupt-IN packets. But soon in a while, ReadFile(GetOverlappedResult) often fails and Windows returns ERROR_DEVICE_NOT_CONNECTED.
- There is no device disconnection recorded in an USB traffic.
-
Try adding a delay between detecting the device and starting communications. If you can eliminate the error that way, you can look for a more elegant way to deal with it.
-
Thank you very much, Jan. I will try.
-
As far as I've observed, the problem is caused when I install a device that is HID vendor defined. If a device is a HID keyboard or mouse, it does not occur. It is caused in WinXP and Win7, but not in Win8 and Win8.1.
-
Try the delay as I suggested. You could also try the suggestion to add a hub between the device and PC. If that fixes it, it's likely something in your device firmware that is having trouble with the host controllers.
-
The touble is also caused if a device is an off-the-shelf one. So I don't think that the root cause is in the firmware.
-
Do you see it only when using the host application you've described?
-
After getting a handle for a device(interface), my test program repeats HidD_GetAttributes() with some interval of time, e.g., 25ms. The API completes successfully at the beginning, and soon it begins to fail; GetLastError() returned ERROR_DEVICE_NOT_CONNECTED. After some seconds, it comes to complete successfully again.
I think there is nothing special in my program and you can easily reproduce the trouble.
-
HidD_GetAttributes should generate no USB traffic; it just returns information collected during enumeration. However, if the device has, for example, failed to respond (even with NAK) to interrupt IN token packets, Windows may stop trying to communicate or may reset and re-enumerate. When you get the error, if possible, see if the device is present in Device Manager.
Are you calling HidD_GetAttributes repeatedly for a different device each time or repeating the call for the same device? If it's the latter, why? If you increase the delay, does the problem go away?
-
I have confirmed that the USB hub driver does not lose sight of a device even when HidD_GetAttributes fails and GetLastError returns ERROR_DEVICE_NOT_CONNECTED.
I have a composite device that has two interfaces, one of them is keyboard and the other is vendor defined. If I get a handle for an interface of the keybord and repeat HidD_GetAttributes, every call of the API completes successfully. But if a handle is for the vendor defined one, the problem occurs.
The behaviour of HidD_GetAttributes is different depending on an interface.
-
Why are you calling HidD_GetAttributes repeatedly for the same device? If you increase the delay, does the problem go away?
-
It's just for my test in order to observe the behaviour of the host.
If I interleave enough delay after getting a handle, no problem occurs.
-
If adding a short delay after getting a handle fixes it, maybe that is all you need to do, especially since you likely need to get a handle only once each time you run the application.