|
|
Hi,
I'm writing an application based on the Screamer example code and I'm seeing strange behavior from the WaitForXfer method. At least, I think it's strange based on how I've seen WaitForXfer used in the code examples. Also, the documentation doesn't give much in the way of details.
In my program, I'm trying to read a continuous stream of data from a bulk endpoint using the queued overlapped-transfer methodology provided in the Screamer example code (see the code's XferThread, LockNLoad and XferData methods). In fact, I haven't changed much in that section of the code, except for adding a wait loop at the WaitForXfer call and writing the incoming data to file every one cycle through the queue.
My problem is that WaitForXfer always returns FALSE, meaning it has timed-out waiting for the OS to signal that the requested data has arrived. This is wrong, because I can see in USBlyzer (a sniffer program) that the requests are going out on the USB (from the preceding BeginDataXfer calls) and that the expected data is arriving from the device. My program sits in a loop, calling WaitForXfer multiple times and waiting for it to return TRUE, so that the program might proceed to call FinishDataXfer and write the data to a file. Even though the data has already come in, WaitForXfer never indicates its presence (seems to me that it should), and so my program stays in the wait loop. I'm giving WaitForXfer a reasonable timeout of 500ms. Since CyUSB is a black-box, I'm not sure how to troubleshoot this any further.
Is my understanding of WaitForXfer's intended behavior correct?
Can anyone provide some insight into what the problem might be?
I'm using Windows XP and SuiteUSB 2.0.
Thanks
|
|
|
That's good advice. Thank you.
...but my problem appears to be that hEvent does not get signalled in the first place. Using a USB protocol-analyzer program, I can see the requests (from BeginDataXfer) going out to my endpoint and I can see requested the data arriving from the endpoint. In my app, however, the call to WaitForXfer always times-out, which seems to indicate that hEvent is never signalled, even though I know the data has already arrived.
...*time passes*...
You just made me think of something and I tried it:
Consider the following snippet from the (working) Screamer example code.
if (!EndPoint.WaitForXfer(ovLapStatus->hEvent, 500))
{
EndPoint.Abort();
PInvoke.WaitForSingleObject(ovLapStatus->hEvent, 500);
}
In my modified version, I had gotten rid of the WaitForSingleObject call because I figured it was redundant, so only the WaitForXfer call remained. Just now, I got rid of WaitForXfer completely and replaced it with a call to WaitForSingleObject, so that my code is now something like this:
if (PInvoke.WaitForSingleObject(ovLapStatus->hEvent, 500) != 0) // signalled == 0
{
// do stuff
}
...and suddenly it works!
WaitForSingleObject sees the signalled hEvent and WaitForXfer does not, even though it may be a wrapper for WaitForSingleObject. WaitForXfer isn't needed at all. It seems we may have found a bug in the SuiteUSB 2.0 version of CyUSB. I wonder how version 3.4 behaves...
Note: FinishDataXfer appears to properly reset the event, so it seems a call to ResetEvent isn't needed.
Thanks!
|
ALL CONTENT AND MATERIALS ON THIS SITE ARE PROVIDED "AS IS". CYPRESS SEMICONDUCTOR AND ITS RESPECTIVE SUPPLIERS MAKE NO REPRESENTATIONS ABOUT THE SUITABILITY OF THESE MATERIALS FOR ANY PURPOSE AND DISCLAIM ALL WARRANTIES AND CONDITIONS WITH REGARD TO THESE MATERIALS, INCLUDING BUT NOT LIMITED TO, ALL IMPLIED WARRANTIES AND CONDITIONS OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT OF ANY THIRD PARTY INTELLECTUAL PROPERTY RIGHT. NO LICENSE, EITHER EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, IS GRANTED BY CYPRESS SEMICONDUCTOR. USE OF THE INFORMATION ON THIS SITE MAY REQUIRE A LICENSE FROM A THIRD PARTY, OR A LICENSE FROM CYPRESS SEMICONDUCTOR.
Content on this site may contain or be subject to specific guidelines or limitations on use. All postings and use of the content on this site are subject to the Terms and Conditions of the site; third parties using this content agree to abide by any limitations or guidelines and to comply with the Terms and Conditions of this site. Cypress Semiconductor and its suppliers reserve the right to make corrections, deletions, modifications, enhancements, improvements and other changes to the content and materials, its products, programs and services at any time or to move or discontinue any content, products, programs, or services without notice.