I have created a case 1V4LNRI on this and have routed it to the concerned engineers. Please let me know if you can access this case. I will keep a close eye on the case.
I have seen and replied to the case you opened. I also attached a text file showing that the unreferenced fixed pointers were optimized out.
i meet this issue. Did this issus is fixed by cypress?
Or we just only use the solution by andrew provided
GCHandle bufHandle1 = GCHandle.Alloc(data, GCHandleType.Pinned);
GCHandle bufHandle2 = GCHandle.Alloc(singleXfer, GCHandleType.Pinned);
GCHandle bufHandle3 = GCHandle.Alloc(overlap, GCHandleType.Pinned);
// send buffers to driver
// wait for driver to finish using the buffers
// get the results of the transfer
any help is appreciate!
It was fixed long back. Are you seeing the exact same error behavior?
I am having a similar problem using the cy8c24894 as a low speed USB control interface (and some other functions) to an FPGA. I keep having issues using xfrdata. I did a one-button test app in C# (VS10) that sends a string to the PSoC, which then echos it back. When I click a button the main thread sends a string. A separate timer thread checks periodically for the echo and puts the echo on the test app GUI. It works for a time, but fails with memory issues. It sometimes won't terminate until I unplug the PSoC, then it terminates immediately. When it terminates on its own, I can re-run the app without resetting the PSoC and it works for a while before it fails again. The one-button test app is copied from the template in the CyUSB.net suite with a timer added. The error I get most often is:
The program ' Template.vshost.exe: Managed (v2.0.50727)' has exited with code -1073740940 (0xc0000374).
Any help would be appreciated; I am trying to bring up the first of two boards which will use this basic architecture.
Update: I got rid of the separate timer thread and just put in a loop that sends a 4 byte buffer string and then waits for a response (the echo) on each iteration of the loop. It almost always hangs on the receive of the 32nd packet.
I concur there is a bug. I made my own xferdata function using the code posted on 3/10 and replacing the fixed directives with Andrew's GCHandle.Alloc suggestions. At this point I can make the problem come and go by changing the name of the called function from the re-written xferdata function to the library function without changing anything else. Proof positive for me, but I don't understand why it works. The fixed directives should do exactly the thing (ie. prevent the garbage collector from prematurely reclaiming transfer buffers), but one works and one doesn't.
For what it's worth:
I've also ran into this issue, and Andrew's solution solved it for me.
I'm using a queue, so after creating each buffer for that queue, I pinned them. At the very end of program operation, I Abort() my enpoint once for each queued call, and then Free() the handle. This way, we're reaching 19MB/s in a stable way (possibly more, but we're targeting 19MB/s).
Thanks for sharing this details here.