USB Superspeed Peripherals

I have implemented a working GPIF state machine that captures N individual lines of data, with one DMA buffer the size of one line.  At the end of acquisition, the state machine loops indefinitely at the final state waiting for a vendor command to reset the acquisition for a new frame.

I've been struggling with commiting/flushing data however.  I'll either get the last line of one acquisition prepended to the start of the next, or the current acquisition never completes (Begin/Wait/FinishDataXfer will time out), depending on the size of the acquisition. 

Things that are unclear to me:

1)  Do I need to flush  at the end state of the GPIF if I've made sure to capture exactly one buffer of data?  It seems like if I don't flush I may or may not get data returned.  

2)   I'm really confused about the remark in the reference manual saying that I need to read data while doing a commit to avoid a zero length packet.  I tried this (forcing the acquisition to end with a half full buffer), and without it the acquisition did not return data. With the read data it did, but I get one extra sample.  Is that expected?   

3)  For CY_U3P_DMA_TYPE_MANUAL_MANY_TO_ONE, is the callback called during the FLUSH state?  Or only when the buffer is actually full?

I am currently using a USB2 High-Speed FTDI chip for USB-to-SPI conversion. 

I am trying to get the lowest possible time to send multiple, small datagrams over SPI.  I am not too concerned about the time to actually send the bits (so far at least, maybe withFX3 that's a new constraint!) which is only a handful of microseconds.

To test the speeds, I perform a loop to send 6 bytes back-to-back (Windows 10, 6-core Xeon, C#) 100 times then calculate the average time with the following psuedocode:

1. Start stopwatch

2. Chip select assertion

3. Read+Write 6 bytes over SPI bus at 10 MHz clock

4. Chip select de-assertion 

5. Repeat #2 through #4 until 100 cycles are reached 

6. Stop Stopwatch

7. Calculate average total time per SPI transaction (= Elapsed time of stopwatch divided by 100)

This yields about 700 microseconds per SPI transaction (on average) when the computer is doing nothing but running this loop, so it's probably a best-case situation.

Here's my questions: 

1. If I use GPIO-controlled slave-selects with FX3, what is an estimate of the total cycle time I would see per SPI transaction (assume 6 bytes transfer, 10MHz clock)...can that 700 microseconds number drop substantially?

2. Would this be done with DMA mode or register mode?  If the number could be dropped low enough I could test with some dummy writes and an oscilloscope with an FX3 eval to ballpark it.

This isn't a legally-binding number :).

I'm just trying to estimate if it would be worth testing something with an FX3 eval board for example.  If that 700 microseconds could come down to below something like 150 microseconds I would consider spending time on it, but if you think it's not going to get that low I would pass and live with what I have.

Thanks.

Hi

I experience an FX3 EP_IN data transfer stop problem. Our design is based on the uvc_cdc example design.

UVC channel is auto_many_to_one DMA, the setting is:

dmaMultiConfig.size = 16384;
dmaMultiConfig.count = 4;
dmaMultiConfig.validSckCount = 2;
dmaMultiConfig.prodSckId [0] = (CyU3PDmaSocketId_t)CY_U3P_PIB_SOCKET_0;
dmaMultiConfig.prodSckId [1] = (CyU3PDmaSocketId_t)CY_U3P_PIB_SOCKET_1;
dmaMultiConfig.dmaMode = CY_U3P_DMA_MODE_BYTE;
dmaMultiConfig.notification = CY_U3P_DMA_CB_PROD_EVENT | CY_U3P_DMA_CB_CONS_EVENT;

dmaMultiConfig.consSckId [0] = (CyU3PDmaSocketId_t)(CY_U3P_UIB_SOCKET_CONS_0 | CY_FX_SOCKET_UVC);
dmaMultiConfig.prodAvailCount = 0;
dmaMultiConfig.prodHeader = 0; /* 0 byte UVC header to be added. */
dmaMultiConfig.prodFooter = 0; /* 0 byte footer to compensate for the 12 byte header. */
dmaMultiConfig.consHeader = 0;
dmaMultiConfig.cb = CyFxUvcDmaCallback; /* use Capture mode's DMA callback */

apiRetStatus = CyU3PDmaMultiChannelCreate (&glChHandleUVCStream,
CY_U3P_DMA_TYPE_AUTO_MANY_TO_ONE,
&dmaMultiConfig);

CDC channel is manual DMA, the setting is:

/* Create a DMA_MANUAL channel between UART producer socket and USB consumer socket
* Use a smaller buffer size (32 bytes) to ensure that packets get filled in a short time.
*/
dmaCfg.size = 32;
dmaCfg.count = 32;
dmaCfg.prodSckId = (CyU3PDmaSocketId_t)(CY_U3P_LPP_SOCKET_UART_PROD);
dmaCfg.consSckId = (CyU3PDmaSocketId_t)(CY_U3P_UIB_SOCKET_CONS_0 | CY_FX_SOCKET_CDC);
dmaCfg.notification = CY_U3P_DMA_CB_PROD_EVENT;
dmaCfg.cb = CyFxUART2USBDmaCallback;

apiRetStatus = CyU3PDmaChannelCreate (&glChHandleUarttoUsb,CY_U3P_DMA_TYPE_MANUAL, &dmaCfg);

Test setting is:

An app from host PC connect with FPGA through CDC channel. This app enable FPGA to generate UVC traffic, after this the app doing nothing, so there is no traffic flow on CDC channel.

Window "Camera" play video FPGA generated (sent to host PC through UVC channel). The rate is about 320M Bytes per second (90% of GPIF bus bandwidth)

The traffic stop is random, some time in a few minute, sometime a few hours, most time never happens. I am able to reproduce this problem by adding 4 hubs between host PC and device. 

Most time when UVC traffic stop, CDC upstream traffic stop as well, CDC downstream traffic is still ok.

If I build FX3 firmware with SDK1.3.3, I can resume CDC upstream traffic by close and re-open host PC app(close and open uart port). UVC traffic can be recovered by changing video channel (in side FX3, uvc related endpiont and DMA channel will be deleted and re-created).

If I build FX3 firmware with SDK1.3.4, this problem will happen much much less often, but once happens, host PC apps freeze, I have to unplug USB cable to close apps, but in one time after about 20 seconds, CDC and UVC channel recovered by itself.

I used a USB analyser to capture traffic to and from FX3, there is no CRC error, the traffic stop is because FX3 send a NRDY transaction packet to host PC (there is no ERDY transaction packet send out by FX3 after NRDY)

Following is a screen shot of some captured data, there are about 30 to 50 unexpected transaction (in class view of usb analyzer) before NRDY, but they look the same as those good one.

Any one has any idea about this please give me a help, Thanks! 

Hi,

I followed this link for configuring my FPGA using the FX3.

I'm using the FPGA configuration Utility given along with the application note.

Bitstreams with size less than 4MB work fine, but with bitstreams greater than 4 MB, the response is unpredictable.

With USB2.0 port, it almost always fails, and with USB3.0, it passes,  sporadically (20-30% of the time). 

I saw this thread: https://community.cypress.com/t5/USB-Superspeed-Peripherals/Maximum-transfer-size-for-BeginDataXfer-FinishDataXfer-with-bulk/td-p/138780, where it's said that the size is limited by the host (Windows), and there's also a Cypress driver which supports bulk transfers up to 32 MB.

I have two questions for this:

1) Is there a plan to release signed drivers which have a 32 MB limit?

2) If we have to avoid this limit (4MB or 32 MB), what modifications should be made to AN84868?

你好，我使用一个uvc工具验证发送设置camera 图像对比度，饱和度命令，但是CyU3PUsbRegisterSetupCallback(CyCx3AppUSBSetupCB, CyTrue)注册的回调函数不响应，函数头里加了日志也没有通过串口打印出来。此uvc工具直接测试usb camera摄像头是有效果的。我想咨询一下，fx3需要如何注册回调函数才会响应类似命令？

Hi

I am developing a firmware that streams data  at 1080p@30 fps, I have  attached the parameters given I am not able to do streaming , the project is also attached , Is there any wrong configuration setting.

Thanks in Advance

Hi,

I am facing an issue with SDK 1.3.4 while using multi thread. I have ported a project source to SDK 1.3.4 that I already used in SDK 1.3.1. I have not changed anything in my source code, I just build the source with 1.3.4. 

In firmware we are just getting commands from HID call back, once I received command in HID call back I will set a event and in another thread I will wait for that event once I received the event I will perform my things. This simple concept is not working if I build my project in SDK 1.3.3 or SDK 1.3.4. Please help us to solve this issue at earliest.

Thanks and Regards,

Vignesh Kumar R.

Hi

We have application of video stream and we are using Bulk transfer, Our frame size transfer are around 8.1MB. We tested the our application where Window 7 64bit can run up to 10000 frames without failure. Then we tested several Window 10 64 bit machine, it can fail randomly. For example we let our application run 1000 frames and it can fail 10 to 20 frames randomly, sometimes even more. 

Test condition: Both Host application and Firmware and Bit files are the same. The only different are Two machine, Window 7 64 bit and Window 10 64Bits

Do you have any idea on this?

Thanks!

Hi all,

I am very new to the FX3 and I am trying to stream data from a 32 bit bus sampled at 10MHz to the computer. Data is sampled on the GPIF using two alternating threads. A program written on linux using libusb and cython simply reads 2MB of data (for now) and dumps it to the disk. 

Currently, I have a testbench set up to generate a 16-bit binary counter to be sampled. However, looking at the dumped data returned, there are (seemingly random) gaps in the data where the counter will jump values. I cant seem to find any consistency as to where the data drops and how much will be lost. 

Is there any way to figure out how to avoid packet loss?

Thanks!

Hi,

according to this thread https://community.cypress.com/t5/USB-Superspeed-Peripherals/FX3-change-packet-size-in-ISOC-module-USBIsocSourceSink/m-p/206286#235342

i was able to change the CY_FX_ISO_MAXPKT parameter.

when Running OUT Traffic (from the EP_OUT) from the streamer GUI, i was able to see in USB3 Trace that the Data len that my host is sending is actually the one that i defined in CY_FX_ISO_MAXPKT parameter.

my problem here is when i want to test the other way, IN_EP from the streamer GUI.

when choosing the IN_EP from the Streamer GUI and press on start, im able to see that there is traffic but in the USB3 Trace i see that the Data Len that the FX3 sending is always 0 no matter what CY_FX_ISO_MAXPKT is configured.

only when CY_FX_ISO_MAXPKT = 1024 i able to see that the FX3 is success to send ISOC Data Packet with Len = 1024 (verified it in the USB3 Trace).

is there something else that i need to configure? or maybe i miss something here? 

more details (from the USBIsocSourceSink module) :

/* ISO Mult settings for SS and HS operation. */
#define CY_FX_ISO_PKTS (1)

/* Burst length in packets supported by the ISO endpoints, when operating in USB 3.0 mode. */
#define CY_FX_ISO_BURST (1)

/* Dma buffer size multiplier. As ISO endpoints will only transfer ISO_PKTS * ISO_BURST packets of data in*/
/* each interval, this can be set to 1 without any performance limitation. */
#define CY_FX_DMA_MULTIPLIER (1)