USB superspeed peripherals

Hi there,

We are seeing an issue with our design that is very similar to

Solved: CYUSB3014 freezes during Slave FIFO transfer - Infineon Developer Community

Solved: Re: How to debug device stall - Infineon Developer Community

Solved: FX3 Superspeed communication fails on link errors - Infineon Developer Community

however none of the above provides a definite answer.

Let me outline the test design, that is basically your slave FIFO example: we have an FPGA interfacing with the controller, and that FPGA pushes 4096x32 bits into the controller whenever a DMA buffer becomes available (both FLAGA and FLAGB high). The USB controller FW only has an additional IIC block, otherwise identical to the example files. Attached the modified .h and .c files. On the PC side we try to do continuous bulk IN transfers either with our c# software or your Streamer app.

What we see is the following:

In most cases (4 out of 5 or so) there are no issues and transfer progresses continuously at the expected 380 MBps or similar speed, for extended periods of time (tens of minutes).

In other cases the controller seems to initialize in a "strange" state. Not sure whether this is Windows10 or driver or FW or electronics issue, but the above bulk IN transfer fails after a few seconds or tens of seconds, stalling/freezing the controller. Soft reset temporarily resolves the issue and data transfer continues, but to fail again and again after short periods of time. What I found to resolve the problem is a hard reset of the controller (either pin C5 or CyU3PDeviceReset(CyFalse);) followed by a reprogram.

My questions:

1. Could you please advise on what causes this issue and how to solve it without having to hard reset?

2. Am I right saying that reset via pin C5 and CyU3PDeviceReset(CyFalse); are *exactly* the same or are there any differences between these?

Many thanks in advance,

Gergely

We use the FX3 slave FIFO interface between USB and an FPGA device as described in AN65974  and observe that after ending the software it is not longer possible to communicate if the USB is meanwhile disconnected and reconnected or the PC powered down. It is still possible to read an EEPROM via endpoint 0 and I2C, but the 32-bit synchronous slave FIFO interface of GPIF2 in automatic mode does not longer work. I tried to use VBATT instead VUSB as primary supply by using CyU3PUsbVBattEnable, but it did not help. It is necessary to switch the power of the device off and on before it works again.

Do you have any suggestions or hints?

I want to configure the GPIF II interface of CYUSB3014 in 32-bit parallel bus + Slave FIFO mode (bidirectional).

This clock frequency is stated in the data sheet as a maximum of 100MHz, but is it variable if it is 100MHz or less?
I want to change to 50MHz / 66MHz / 80MHz.

Also, if I change the clock frequency, do I need to change the FW? If it is yes, where and how should I change it?

Thanks,
Tetsuo

Hello, I'm looking for some technical info concerning your CYUSB3065 device. In the datasheet I see that the device is USB 2.0 compatible and I'd like to know if that means it can communicate over the USB2.0 D+/D- lines only and if there are any band width restrictions when used in the USB2.0 only mode.

Looking forward to hearing back

Hi, I am interfacing a qvga sensor to my FX3 board. configured it according to AN75779 reference doc. I traced the data on wireshark and as per the calculation, it shows me the buffer data more than the 1 frame size. What could be the reason?
where I should look into it?

please suggest~

Regards.

Hello, we would like to interface an FX3 controller via C library calls (or via Python ctypes). Do you provide a DLL for CyApi? I could only find the static CyApi.lib or the dynamic CyUSB.dll (which is a .NET DLL and does not export functions). Thanks!

I'd like to bump up a question from 2016:

Has the python library for the cyusb.dll been developed/released as yet? Can you give an update on a schedule if there is one?

Hello.

I am using the Streamer Application  from SDK1.3.4 with the SuperSpeed Explorer Kit.  When I plug the setup into a USB3 port that is part of the motherboard, all is fine and I can get transfers approximately 4.3Gbps.  There are no failures.  I am just using the default settings that the Streamer Application starts with.  All looks good and is okay.

However, when I try to use a RocketU 1244A USB3 add-in card with the default settings,  I get approximately 200 Successes and then it just keeps failing.  The transfer rate just decreases to 0 if I let it run over time.  After the initial successes, everything is failure.

The settings are BULK IN, packets per xfer=32, xfers to queue=16.  Which is the default.

After trying numerous different things, it appears that the 1244A card cannot queue up any more than one DeviceIoControl() buffer at a time?  Other cards, in addition to the motherboard usb ports, appear to allow queuing up multiple buffers simultaneously via DeviceIoControl().

If I make the packets per xfer=1 and xfers to queue=1 in the Streamer Application with the 1244A card, I can get no failures but the transfer rate is 0.043Gbps (much slower).  Are you aware of any limitations in using DeviceIoControl() with the 1244A USB3 PCIe card?

Frank

Hi,

I am using the CYUSB3KIT-003 EZ-USB™ FX3 SuperSpeed Explorer Kit connected to an FPGA through the GPIF interface.

The transmission from FPGA to the FX3 works fine, whereas in the other direction I have some issues.

15 out of 32 data signals are driven high properly, i.e. they reach more or less the 3.3V value; the other 17 instead can only reach a value of 2V. In addition, there is a voltage drop on the 22-ohm series resistors of these 17 signals, meaning that there is a current flowing somewhere (about 20-30mA, but still I am wondering how is it possible, since it is connected to an FPGA pin, that is high Z).

Dually, the above 15 data signals are not driven down to 0V, as they reach 1V (and there is the same voltage drop across the series resistors), whereas the other 17 can go down to 0V. All 32 signals are connected to the same FPGA bank.

I have tried everything possible downstream of the FX3 pins, so it seems that the culprit of this cumbersome behavior is the FX3. The firmware code is taken from an example provided and slightly adapted. The GPIF designer was used to generate the .h file to include. 

So my question is if I am missing a pin setting or something else in the configuration process. But the strange thing is that half of the pins behave in the opposite manner with respect to the other half.

Thank you