WinUsb timing issue

Hi,

We are trying to use WinUsb to communicate with our own hardware device.
However, we're experiencing strange timing issues, where regularly the driver
fails to retrieve the reply from the hardware device.

The same code works fine with another driver, which is just a build of the
bulk USB driver sample from the DDK.

One difference between the two drivers is that WinUsb requires the handle to
be created with the FILE_FLAG_OVERLAPPED attribute, while the other driver is
not. This sounds like a good reason that we would get these timing issues,
because that allowes multiple simultaneous pending read and write requests,
but in our case we never make a new WinUsb_WritePipe() or WinUsb_ReadPipe()
call before the previous one is complete. We are doing synchronous calls only.

Seen from the application side, the WinUsb_ReadPipe() call just fails and
GetLastError() returns 121, which is semaphore timeout, so I guess the
request just times out.

Any ideas as to what we can do differently or try to make the communcation
stable with WinUsb?

If you need additional information about our setup etc, please let me know

/Kenneth

Kenneth,

Your post almost exactly describes what I am experiencing.

I have been fighting this problem for a couple of days now to no avail.

Did you find a solution?

/Steve



Kenneth Adelhorst Andersen wrote:

WinUsb timing issue
25-Nov-09

Hi

We are trying to use WinUsb to communicate with our own hardware device
However, we are experiencing strange timing issues, where regularly the drive
fails to retrieve the reply from the hardware device

The same code works fine with another driver, which is just a build of th
bulk USB driver sample from the DDK

One difference between the two drivers is that WinUsb requires the handle t
be created with the FILE_FLAG_OVERLAPPED attribute, while the other driver i
not. This sounds like a good reason that we would get these timing issues
because that allowes multiple simultaneous pending read and write requests
but in our case we never make a new WinUsb_WritePipe() or WinUsb_ReadPipe(
call before the previous one is complete. We are doing synchronous calls only

Seen from the application side, the WinUsb_ReadPipe() call just fails an
GetLastError() returns 121, which is semaphore timeout, so I guess th
request just times out

Any ideas as to what we can do differently or try to make the communcatio
stable with WinUsb

If you need additional information about our setup etc, please let me know :

/Kenneth

Previous Posts In This Thread:


Submitted via EggHeadCafe - Software Developer Portal of Choice
ASP.NET Application-Page Lifecycle Redux
http://www.eggheadcafe.com/tutorials...ationpage.aspx

Hi Steve,

I'm not sure I would say that I've solved the problem, but I've found a
workaround anyway... It turns out that instead of letting WinUsb split up the
packages into 64 byte slices (which is the package size of the USB standard),
if I split up the packages myself and never send anything bigger than 64
bytes to WinUsb, I don't get these timeout issues.

I suspect that this is because the WinUsb driver uses overlapped I/O, so
maybe it will actually make simulatenous concurrent requests to the device,
if I pass it a big package, and my device is probably not capable of handling
that correctly.

Having said that, I still have some timing issues left in other cases, but I
can easily retry my way out of these. I don't think we'll have time to figure
out these last issues, since they do not appear to be show stoppers.

Hope this helps,
/Kenneth



"Steve Floyd" wrote:

> Kenneth,
>
> Your post almost exactly describes what I am experiencing.
>
> I have been fighting this problem for a couple of days now to no avail.
>
> Did you find a solution?
>
> /Steve
>
>
>
> Kenneth Adelhorst Andersen wrote:
>
> WinUsb timing issue
> 25-Nov-09
>
> Hi,
>
> We are trying to use WinUsb to communicate with our own hardware device.
> However, we are experiencing strange timing issues, where regularly the driver
> fails to retrieve the reply from the hardware device.
>
> The same code works fine with another driver, which is just a build of the
> bulk USB driver sample from the DDK.
>
> One difference between the two drivers is that WinUsb requires the handle to
> be created with the FILE_FLAG_OVERLAPPED attribute, while the other driver is
> not. This sounds like a good reason that we would get these timing issues,
> because that allowes multiple simultaneous pending read and write requests,
> but in our case we never make a new WinUsb_WritePipe() or WinUsb_ReadPipe()
> call before the previous one is complete. We are doing synchronous calls only.
>
> Seen from the application side, the WinUsb_ReadPipe() call just fails and
> GetLastError() returns 121, which is semaphore timeout, so I guess the
> request just times out.
>
> Any ideas as to what we can do differently or try to make the communcation
> stable with WinUsb?
>
> If you need additional information about our setup etc, please let me know
>
> /Kenneth
>
> Previous Posts In This Thread:
>
>
> Submitted via EggHeadCafe - Software Developer Portal of Choice
> ASP.NET Application-Page Lifecycle Redux
> http://www.eggheadcafe.com/tutorials...ationpage.aspx
> .
>

winusb does not split transfers up into max packet sized transfers, the
underlying usb host controller does that. winusb just sends the entire
buffer as is to the device

d

--

This posting is provided "AS IS" with no warranties, and confers no rights.


"Kenneth Adelhorst Andersen" <> wrote in message
news:F515D4E9-BD1E-4D79-BBB3-...
> Hi Steve,
>
> I'm not sure I would say that I've solved the problem, but I've found a
> workaround anyway... It turns out that instead of letting WinUsb split up
> the
> packages into 64 byte slices (which is the package size of the USB
> standard),
> if I split up the packages myself and never send anything bigger than 64
> bytes to WinUsb, I don't get these timeout issues.
>
> I suspect that this is because the WinUsb driver uses overlapped I/O, so
> maybe it will actually make simulatenous concurrent requests to the
> device,
> if I pass it a big package, and my device is probably not capable of
> handling
> that correctly.
>
> Having said that, I still have some timing issues left in other cases, but
> I
> can easily retry my way out of these. I don't think we'll have time to
> figure
> out these last issues, since they do not appear to be show stoppers.
>
> Hope this helps,
> /Kenneth
>
>
>
> "Steve Floyd" wrote:
>
>> Kenneth,
>>
>> Your post almost exactly describes what I am experiencing.
>>
>> I have been fighting this problem for a couple of days now to no avail.
>>
>> Did you find a solution?
>>
>> /Steve
>>
>>
>>
>> Kenneth Adelhorst Andersen wrote:
>>
>> WinUsb timing issue
>> 25-Nov-09
>>
>> Hi,
>>
>> We are trying to use WinUsb to communicate with our own hardware device.
>> However, we are experiencing strange timing issues, where regularly the
>> driver
>> fails to retrieve the reply from the hardware device.
>>
>> The same code works fine with another driver, which is just a build of
>> the
>> bulk USB driver sample from the DDK.
>>
>> One difference between the two drivers is that WinUsb requires the handle
>> to
>> be created with the FILE_FLAG_OVERLAPPED attribute, while the other
>> driver is
>> not. This sounds like a good reason that we would get these timing
>> issues,
>> because that allowes multiple simultaneous pending read and write
>> requests,
>> but in our case we never make a new WinUsb_WritePipe() or
>> WinUsb_ReadPipe()
>> call before the previous one is complete. We are doing synchronous calls
>> only.
>>
>> Seen from the application side, the WinUsb_ReadPipe() call just fails and
>> GetLastError() returns 121, which is semaphore timeout, so I guess the
>> request just times out.
>>
>> Any ideas as to what we can do differently or try to make the
>> communcation
>> stable with WinUsb?
>>
>> If you need additional information about our setup etc, please let me
>> know
>>
>> /Kenneth
>>
>> Previous Posts In This Thread:
>>
>>
>> Submitted via EggHeadCafe - Software Developer Portal of Choice
>> ASP.NET Application-Page Lifecycle Redux
>> http://www.eggheadcafe.com/tutorials...ationpage.aspx
>> .
>>

After successful calls to WinUsb_WritePipe & WinUsb_ReadPipe (no packet over 64 bytes long), a call to one or the other will fail to work. The error given is: 0x00000079: The semaphore timeout period has expired.

No matter what I do from the windows application, e.g., connect, disconnect, read, write, including stopping & restarting the windows application, the problem remains. Only when I physically disconnect the USB cable and reconnect it does the problem go away. Then again, after a few successful WinUsb_WritePipe and WinUsb_ReadPipe calls later, it begins to timeout again.

One possible clue... in the debugger on the device side, we saw in the firmware that on the first failed call, the device only received 8 bytes from the host, instead of the 61 bytes that were sent. timeouts started after this.

Does this "smell" like a driver issue? What is a good driver to use?

Steve

Morpheus <> wrote:
>On Dec 4, 7:06*pm, "Doron Holan [MSFT]"
><doron.ho...@online.microsoft.com> wrote:
>> winusbdoes not split transfers up into max packet sized transfers, the
>> underlying usb host controller does that. *winusbjust sends the entire
>> buffer as is to the device

Overlapped I/O makes no difference at all at the device level. All
requests to a single endpoint are always serialized. The only thing that
overlapped I/O changes is that you have another request ready to go just as
soon as the first request completes, rather than waiting for a round trip.
--
Tim Roberts,
Providenza & Boekelheide, Inc.

Hi Steve,

I too facing similar kind of problem, When I call WinUsb_WritePipe from my application, it returns error code 121, ie., "The semaphore timeout period has expired.
".


as you said after unplug and plug, the device started working fine.

anybody have solution to fix this issue ?

-Pradeep-