1 2 Previous Next 23 Replies Latest reply on May 7, 2013 5:02 AM by prajithc_ Go to original post
      • 15. Re: CyAPI.NET bug
                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.   
        • 16. Re: CyAPI.NET bug
                  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.   
          • 17. Re: CyAPI.NET bug

             hi all, 


            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!



            • 18. Re: CyAPI.NET bug

              It was fixed long back. Are you seeing the exact same error behavior?





              • 19. Re: CyAPI.NET bug

                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 '[1896] 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.



                • 20. Re: CyAPI.NET bug

                   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.

                  • 21. Re: CyAPI.NET bug

                    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.

                    • 22. Re: CyAPI.NET bug

                       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).

                      • 23. Re: CyAPI.NET bug



                        Thanks for sharing this details here.



                        1 2 Previous Next