Check the error code returned from the transfer methods using UsbDStatus API.
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.
Do you mean not able to communicate to PSoC through USB?
When you plug the device in what is the behavior being seen?