USB superspeed peripherals Forum Discussions
Hello,
We are using FX3 to realize the communication between FPGA and our host computer, and we hope to use GPIF II master mode to control the data transmission of FPGA. We assume the following scheme:
we use a MANUAL_IN DMA channel between GPIF and USB bulk in endpoint.
(1) At the beginning, the GPIFII state machine is in a waiting state. Do not write data to the DMA buffer at this time;
(2) When the Host application, such as Control Center, needs 256 bytes of data, click Transfer Data In, then the state machine change to a new state, and starts InData action;
(3) After clicking Transfer Data In, FX3 needs to send a signal to FPGA, we call it BEGIN signal here;
(4) When the BEGIN signal is high, the FPGA writes data to the 32-bit data line of GPIF II; After 256 bytes of data is written, the BEGIN signal becomes low, the FPGA stops writing data, and the GPIF state machine returns to the wait state.
In short, we hope that FX3 can control the FPGA according to the data size filled in the host application, and let the FPGA write the corresponding size of data to the DMA buffer.
Is the above idea feasible? if yes, how to set the GPIF state machine, to write data into DMA buffer only when the host application needs data?
If not, is there any good suggestion that FX3 can transfer the latest data collected by FPGA to the host every time the host needs data?(Our FPGA is used for data acquisition and will be in a continuous working state. At first, we adopted a scheme similar to AN65974, but because the host computer could not take out the data in time, the FPGA has to stop writing the data when DMA buffer is full, and our users did not want this)
Or, can you give us some other plans or suggestions?
Thank you,
Fan
Show LessHi,
im using cy3014 to config my FPGA, so the .img file is around 4mb size. It takes more than 7 minutes to program flash by use USB Control Center software or use DownloadFw function. how to improve it?
other question is about SPI speed, I tried to use CyU3PSpiReceiveWords functions to read data from flash, cy3014 take 1.2us between every byte Received, how to reduce it?
Show LessHey we are currently using Slave fifo use case with our FGPA. Due to some design concerns, we hope FX3 to be able to collect continuous data from FGPA. Which mean we can't use flags or flagb to pause data transfer on FPGA side.
To achieve this goal, is that possible that we modify GPIF to make it automatically switch sockets in one cycle? So for Stream IN mode, the socket could be:
Socket_0, Socket_2 are used by GPIF as producer
Socket_1 is used by USB EP IN as consumer
DMA buffer size is 4
FX3 working as following steps:
1. FPGA update DQ with 80Mhz(our system requirement), on socket_0 to buffer_0
2. If socket_0 and buffer 0 is full, at next DQ update cycle, GPIF will automatically switch to socket_2 and start to fill in buffer_1. In the mean time, USB will empty buffer_0 by socket_1
3. If socket_2 and buffer_1 is full, at next DQ update cycle, GPIF will automatically switch to socket_0 and start to fill in buffer_2. USB will empty buffer_1 by socket_1
4. If socket_0 and buffer_2 is full, at next DQ update cycle, GPIF will automatically switch to socket_1 and start to fill in buffer_3. USB will empty buffer_2 by socket_1
5. If socket_1 and buffer_3 is full, at next DQ update cycle, GPIF will automatically switch to socket_0 and start to fill in buffer_0. USB will empty buffer_3 by socket_1. And Go back to step 1.
Since data updating speed is less than 320MB/s, speed should be enough
Show LessI am trying to create a firmware which will enumerate the FX3 chip as a UVC camera which gets its video data from an internal FPGA. Our internal structure is very similar to the slfifosync example project, so I am using that as a base and then putting the UVC layer above it, however when I install the firmware and try to use the device, I am getting the following error in the Windows Camera app: "0xA00F4241 <CameraSwitchFailed> (0x80070018)" and I am not sure what is going wrong.
I am currently trying to get the device recognized as a camera with the ability to be opened in the application. When I use the unmodified cyfxuvc_an75779 example (which I am basing my UVC layer off of) it is recognized as valid camera and has a simple black screen as output. My application doesn't currently route any video data to the USB endpoint; I am just trying to get a black screen out.
Looking at the USB traffic with wireshark, the device looks to be properly enumerating but when I open it in the Camera app the device it stalls on the host's UVC probe request. I have checked the cyfxuvc_an75779 example and have the same endpoint 0 structure and signal handlers. I have removed all references to USB 2 in the descriptors and UVC firmware code. Any help in diagnosing the issue would be appreciated!
Show LessHello,
Webcam provides only isochronous endpoint for data transferring. Bulk is not supported as we know.
Therefore it looks quite obivious that the USB 2.0 host firmware which deals with webcam as a device should open its endpoint as isochronous. A question on this was dealt in the following thread.
In an effort to receive webcam MJPEG stream in my host firmware, I'm facing a problem which I can't reasonably explain.
- Test environment
For experiment, I defined macro "BULK" which turns on the setting for bulk transfer and on the other case(When BULK is not defined), isochronous is activated.- - Endpoint and DMA channel is created as below (see endpoint.c)
- - MJPEG stream is received by UvcRecvThread function (see UvcRecvThread.c)
- Test Results
- - isochronous case (when "BULK" is not defined), the full log can be found in "iso.txt".
- - bulk case, the full log is "bulk.txt"
Question
- I thought that the host firmware must use isochronous endpoint because webcam only supports isochronous endpoint. But as we see in the above test, it was also possible to receive data through bulk as well.
- Though I could receive data both in isochronous and bulk mode, there were significant difference between them.
The MJPEG stream is a series of jpegs. A jpeg image starts with SOI(Start of Image, 0xffd8) and ends with EOI(End of Image, 0xffd9). When I searched for the iso.txt, I could find only 1 SOI while 211 EOIs. This means I lost quite a lot of SOIs except the very first one. In contrast, in bulk.txt, I could find 115 SOIs and 127 EOIs.
I think that isochronous endpoint is the right choice but the result is not what I expected. In isochronous case, the result shows I'm missing many important data from the webcam. - Bulk test case seems quite promising regardless if it is a right one or not. In my long term test, after few hours of running, the thread gets stuck.
Regards,
Rossi
Does the Infineon/Cypress EZ-USB CX3 (CYUSB3064-BZXI) and the SDK support a MIPI CSI-2 version 1.1 transmitter?
Also posted to USB-FULL-HIGH-SPEED by mistake.
Show LessHello, I was wondering if the CYUSB3ACC-004A will interface with the Onsemi AR0237IRSH12SPRAH3-GEVB. In the Interconnect boards datasheet it mentions that it interfaces with Onsemi Image Sensors. It looks like the Image Sensor evaluation board matches the connect for the Interconnect board. Or is the interconnect board only to be used for
Thanks
Show LessHi I'm MJ and working on FX3.
Now I'm trying to use low power mode L1 but the current is not that small.
In the datasheet, low power mode L1 current is 2mA.
But when I tested it on the development kit, it was almost 40 mA.
Am I missing something? How can I reduce the current less then 2mA.
Show Less
Hi
The FX3S is connected to two microSD and RAID them.
Recently, we found the last digit of FX3S SN got changed when there's a failed microSD.
The last digit turned from "0" to "1".
For example:
Pass unit --> Axxxxxxxxxxxxxx0
Failed case --> Axxxxxxxxxxxxxx1
Do you have any insight/comment on this?
Much appreciated.
@JayakrishnaT_76 , any chance you happen to know something about this phenomenon?
Show LessHello,
For using MIPI-CSI2 Configuration API, should i surely use I2C bus?
If not, I would like to use SPI bus instead of I2C bus for Sensor(FPGA) configuration because of clock speed.
Thank you in advance
Show Less