USB low-full-high speed peripherals Forum Discussions

Is there an integrated library with the CY7C65631-56LTXC in it.

I am using your Low Power USB 2.0 Hub Controller CY7C65631-56LTXC. I want the schematic and footprint for my Altium library. Is there an integrated ... Show More

By Anonymous

May 2, 2011

397

USB low-full-high speed peripherals

Need help to convert .C code(Keil) for use it with FX2LP.

Hello Form, This is a (uVision2 Project) Keil .C code, wrote for W78E516B microcontroller which is fully compatible with standard 8052. I would li... Show More

By Anonymous

May 7, 2011

373

USB low-full-high speed peripherals

MSD driver on Win7 64bits

Is it possible to make the Windows MSD driver for FX2 work on Win7 64bits ?? If it is, how can I ?? Regards Show More

By Anonymous

Jun 7, 2011

579

USB low-full-high speed peripherals

is there any tutorial for uvision to work with 3684 dkv?

Solved

I am using 3684 DVK. I used dvkUsersGuide.pdf it works fine (those projects have preAdded sources and libraries) Is there any other totorial that ... Show More

By Anonymous

Jun 6, 2011

626

USB low-full-high speed peripherals

Composite HID

Hello, With a CY7C63823, is it possible to implement composite HID? A keyboard and a mouse will be connected to single CY7C63823 via SPI but only ... Show More

By Anonymous

May 24, 2011

314

USB low-full-high speed peripherals

WinUSB with CY7C68013A, Anyone may help me, please?

Hi, Anyone may help me with the follow doubt: It Is possible to use the CY7C68013A with Winusb generic driver? If it is possibe, how ha... Show More

By Anonymous

Oct 19, 2010

644

USB low-full-high speed peripherals

CyAPI.NET bugs

I believe I may have found a few bugs with the CyAPI.NET library. I hope to create some discussion to see whether or not these are really bugs... Show More

        I believe I may have found a few bugs with the CyAPI.NET library. I hope to create some discussion to see whether or not these are really bugs.

First, a doc error. The help says that OverlapSignalAllocSize is a public read-only Property of the CyUSB class. This is not true. It is actually a member of CyUSBEndPoint. This is unfortunate, because it means we need an actual instance of a CyUSBEndPoint in order to call OverlapSignalAllocSize. It would be better if it was a static method as part of the CyConst class, so that it could be called without an instance to any objects.


Second, I want to know if there's a reason that the data transfer buffers are all ref'd. I believe they are ref'd because, in the previous C++ implementation, we needed to pass objects by reference to avoid calling the copy constructor. This is not necessary in C#, because the caller passes the callee a    copy of the reference. What the ref keyword does is pass the    caller's original reference instead of a copy.

I think this was an honest mistake made by a C++ programmer who was learning .NET and didn't know that the ref keyword is very different from the & symbol in a C++ parameter list. However, by forcing the buffers to be ref, the CyAPI.NET library becomes much more awkward to use, as there are severe limitations on what you can pass to a ref parameter.


Finally, and    most seriously, I believe there is a major bug involving passing buffers from Managed to Unmanaged code. This bug could be why everyone has such problems with calling the asynchronous Begin/Wait/FinishDataXfer methods.

First, a brief review of garbage collection. To keep the heap from becoming too fragmented, the CLR is allowed to re-arrange the contents of memory on a whim. It then updates all the Managed references to point to the re-arranged contents accurately. However, the CLR has no way to tell Unmanaged pointers that it has moved the contents of memory around.

Now, I suggest pulling up the help file for BeginDataXfer() and looking at the example. Note the use of the fixed { } block surrounding the creation of the Overlapped's hEvent member. That fixed block is there likely because the compiler complains otherwise, but there's a good reason why we need it.

The fixed keyword tells the CLR that the parameter (in this case, the ovLaps buffer) must be pinned in memory, so that the unmanaged code in the block doesn't get burned by the CLR's garbage collector. This is important because otherwise ovLaps could move somewhere else between the cast to an OVERLAPPED* and the call to CreateEvent, causing CreateEvent to write into memory that might be owned by another process.

Finally, the problem. I was transferring back and forth between the device using worker threads, and noticed that if I used the menu bar, the application would lock up or crash the main thread. I believe that the menu bar was causing a lot of small objects to be created and then freed, which fragmented the heap, causing the CLR to re-arrange memory, moving my buffer while the driver was in the middle of transferring.

This would cause all sorts of problems. Sometimes, my app would lock up. Not even Visual Studio's stop button would end the process. Other times, the main thread (NOT the worker thread!) would throw a NullReferenceException, or even the exotic ExecutionEngineException; I believe this was because the driver was running in the main thread's context while the garbage collector moved the buffer. While somewhat random, the crashes were easy to reproduce and typically happened after only a few seconds. The exceptions and freezing would stop if I commented out the transfer.

The solution is to pin the buffers for the duration of the transfer. ALL of the buffers; the single transfer, the overlapped, and the data buffer. You could do this by using three fixed blocks, however I prefer the    GCHandle class for pinning objects.

I created a class called PinnedBuffer and, in the constructor, I used GCHandle to pin the buffer. I then use this PinnedBuffer class for all three buffers. The byte[] needs to be a public field so that you can use it with the data transfer methods' ref parameters (see the previous issue). I haven't had any problems since I started pinning all my buffers.

I don't know whether the XferData method pins all of its buffers for the duration. I do know that their example code for their asynchronous methods only momentarily pins the overlap buffer and that is probably why people have so many problems with the asynch code.    All three byte[] buffers need to be pinned before the transfer begins until after it finishes.    Show Less

By Anonymous

Feb 1, 2010

1414

USB low-full-high speed peripherals

Hex2bix intermittent under windows 7

Hi all, We've been using EZ-USB for many years to build applications for our products without any problem. Recently we've switched to Windows 7 (3... Show More

By ScGr_289066

May 29, 2011

356

USB low-full-high speed peripherals

basic problem with 3684 dvk

Solved

hi how to make icc file to make 3684 development board work in slave fifo. I know I should write a program to set some registers like IFCNFG... Show More

By Anonymous

May 29, 2011

415

USB low-full-high speed peripherals

CY7C68013A throughput in bulk mode

Hi, I am trying to measure the FX2LP USB chip througput in bulk mode. In order to do so, I have modified bulk example firmware so it continiously f... Show More

By Anonymous

May 25, 2011

431