USB superspeed peripherals Forum Discussions

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 all,

I'm trying to use the AN75779 project as a baseline to set up my MT9P031 as a UVC camera.

Here's what I did:

Modify GPIF state machine: changed to 16 bit wide bus with one clock per pixel, changed LD_ADDR_COUNT and LD_DATA_COUNT limits to 8183 to account for this. Changed the active clock edge to falling.

In order to fake the YUY2 I tied data 15 high and 14:8 low so the upper byte would be 0x80. Then I just attached my most significant 8 bits of my camera bus to data lines 7:0.

Overhaul to the I2C in sensor.c code. The MT9M114 uses two bytes of register addresses in its protocol while the MT9P031 only has one so I had to get rid of the upper address byte in all the functions. I got rid of all of the configuration for MT9M114 and only wrote in commands to set my sensor up to run 720p at whatever rate it runs. I figured initially setting the sensor up to do 720p to match the existing project would be the path of least resistance.

I have a 24MHz clock and the datasheet suggests it would get 60fps with 96MHz so I assume it's actually going to give 15fps instead of 30.

In the UVC Descriptor C file, I've tried just leaving everything alone, as well as increasing the frame time to double or four times the original (so 0xA2C2A or 0x145854) to account for a lower FPS but nothing is helping.

The result is that Windows recognizes the device as a camera and I'm able to select it with the Windows camera app, and I see some response on the debug serial port when I do select or de-select it.

With the additional debug print enabled, I see "UVC: Completed (n) frames and 0 buffers."

Ultimately though I just get a black screen.

Do I need to use the PLL to increase my clock rate to actually achieve 30fps? Or do I need to adjust the minimum bitrate in the descriptor to reflect what the camera actually puts through?

Or am I missing something else?

Thanks in advance!

Hi,
I used cyfxuartlpdmamode example and modified the channel to UART-> CPU ( MANUAL IN) and another channel CPU ->UART (MANUAL OUT). I attached my new firmware.  I used the UART event(UartIsr). I send data from Teraterm, I got ISR after sending 16-bytes(DMA size). I put a fixed buffer, when I got the ISR, I send that data to Teraterm. Up to here, everything is ok. But I have 2 problems:
1- I don't get another ISR. I mean I sent 16 bytes first time, I got letters A to Q (fixed buffer) in Teraterm, but again I entered another 16 bytes and I expected to get another ISR, but I don't get. I think the previous event hasn't had clear, and I don't know how I should do that.(SendDebugMessage(buf, len))

2- When I try to replace the fixed buffer with the input buffer, I got nothing. (SendDebugMessage(buf_p.buffer, len))

Could you please help me on this matter?

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)

FX3 GPIO46 is used as PWM output.  I refer to excel document attached to the thread

https://community.cypress.com/t5/USB-Superspeed-Peripherals/IO-Drive-Strength-configuration-for-P-port-I2C-GPIO-SPI-UART-and/m-p/91050

But in this document, with same IO VDD, IOH, Drive strength, different Forced VDD will result in different drive current for GPIO46. 

1.  What does " forced VDD" mean in the excel file?

2.  What is default GPIO drive strength when no CyU3PSetGpioDriveStrength( ) called to set drive strength, 1/4,2/4,3/4 or 1?

3. Is there difference between simple GPIO and complex GPIO in term of drive strength?

Thank you.

Kelly

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 there,

I had the product Kensington SD 4600P. The ethernet chip is cypress GX3. Just wondering will the driver for CYUSB3610 will be released recently?

Thanks

I'm working with the FX3 right now and I'm just trying to test continuous GPIF capture.  But, I'm running into issues that no matter how slowly I run it still seems to corrupt data when handing of threads on the GPIF bus.

Originally I started with watermarks on the threads and ping ponged based on the water marks, but, after reading through 124206 "Designing a GPIF II Master Interface" I switched to using DATA_COUNTs to handle ping-ponging between threads.

Currently I'm clocking it down at 50 MHz, and I'm capturing 16-bits at a time from the bus.   I can trigger the bus capture and all works well.  I can also see it ping-ponging between each thread at the exact correct time using an external scope with the correct numbers of samples read. 

The only issue is when I look at my USB data stream coming from the FX3, the data has missing(?) or maybe (extra?) frames between each handoff between threads.  It's not an insignificant amount, either.  If it was just a few microseconds all would be well, but it's way wrong.

Here is how I'm currently setting up my state machine:

The reason I think this is the issue, and not USB is because if I adjust the LD_DATA_COUNT, then the corruption happens at that interval.  Additionally, I have tried increasing clock rate to 100MHz on the GPIF bus, and I see the same issues. That said, here is my USB descriptor that I'm using:

My DMA Is set up as follows:

dmaCfg.size = 32768;//Seems to work here and 16384, but smaller values seem to drop data, a lot. Event at 16384 corruption happens.
dmaCfg.count = CY_FX_ISOSRC_DMA_BUF_COUNT; //3 - seems to crash if anything other than 3.
dmaCfg.prodSckId = CY_FX_PRODUCER_PPORT_SOCKET;
dmaCfg.consSckId = CY_FX_EP_CONSUMER_SOCKET;
dmaCfg.dmaMode = CY_U3P_DMA_MODE_BYTE;
dmaCfg.notification = 0; //CY_U3P_DMA_CB_CONS_EVENT; (Currently disabled)
dmaCfg.cb = DMACallback ; //This never seems to be called. Could it need CY_U3P_DMA_TYPE_AUTO_SIGNAL?
dmaCfg.prodHeader = 0;
dmaCfg.prodFooter = 0;
dmaCfg.consHeader = 0;
dmaCfg.prodAvailCount = 0;

What tactic is best for continuous capture?

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?

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?