I have been trying to solove the following issue:
PC side: Two Bulk Endpoints (in, out), the Out endpoint is called from within the GUI thread (i.e. when you press a button). The In endpoint runs on its own thread by calling mDevice->BulInEndpoint->XferData(..........).
On the Emdedded side I have PSoC5 device. Basically I have a while loop:
"if there is data on the PC's out enbdpoint then read it and load it on the PCs in point"
So if the user does not press a button on the GUI, then there is no data flowing; when one presses the button, then a 4-byte packet is sent from the PC to the PSoC5 and looped back to the PC.
This works fine IF the PC's In endpoint does not time out. If the IN endpoint times out, then for some reason the PC is not able to receive data anymore. I have tried different scheemes (using Begin and Finish DataXfer, calling Abort, etc) but none work.
I am programming in .net 2005 (Windows Form).
Now, I have a very simple application , same concept of receiving thread -win32 console app CyAPI.lib, but using one of the FX chips and have no issues. Thus I don't know if is a .net vs win32 issue or what.
Have you tried replicating the issue with CyConsole (it is CyAPI.lib based) ? just to isolate the issue.
Are you forcing the console app as well into the same scenario to check that it handles this scenario properly? i.e. how are you ensuring that the console app is not showing the same behavior as the GUI?
Thank you guys.
I will try both, reading the status of the driver and also writing the same app bu on a win32 console approach.
And yes, I am using the CyAPI.lib in the .net 2005 (C++) app.
The status code:
When I let the IN point to timeout, the status UsbdStatus from the IN point is: 3221291008.
Then I press the button so that the OUT endpoint sends the 4-byte packet; the IN point exits fairly fas with the code: 3221225484
After that the IN point keeps timing out (the usual ~ 5secs) with code: 3221291008.
Where are these codes documented?
The error codes returned in SuiteUSB are standard windows error codes. You should be able to find them in http://msdn.microsoft.com/en-us/library/cc704588(v=prot.10).aspx for NTSTATUS.
One of your error code relates to
STATUS_TIMER_NOT_CANCELED An attempt was made to cancel or set a timer that has an associated APC and the specified thread is not the thread that originally set the timer with an associated APC routine.
I'm not able to locate the other. I'll check and let you know if I find anything more about your other error code.
In the GUI .net 2005 program: When BulkInEndpt timesout it gives: dStatus = 0xC0010000 and nStatus = 0xC0000120.
The Win32 console program gives the exact same codes, but it keeps working fine when a timeout occurs (i.e. I can send data and the PSoC5 will loop it back).
I suspect it has to do with the way the receiving threads are created. In the .net2005 case, the thread is a non-static member of the class Form1. In win32 case the thread is a global function.
I'll make some changes and let you guys know.
I fixed the thread / timeout problem, now the application can send after a timeout in the receive direction.
Now my problem is when I disconnect the USB cable, it seems that the only way to re-establish communications with the PSoC is by resetting the chip.