I have taken UVC (AN75779) as a reference design. in which I have changed the UVC descriptor to USB descriptor (0X83 IN Endpoint) and Using the same GPIF interface.
FPGA is connected to the FX3 through the GPIF interface. From FPGA I am sending counter data 2712 bytes/line and 10848 bytes/frame to the FX3 at 40MHZ speed.
when I am reading the data from the host, I am getting backflow error and DMA commit error because of that I am getting loss of frame and getting some data less than the actual frame size(less than 10848).
Please suggest what can I try to resolve the DMA commit and backflow error.
Please let us know what exactly you meant by the following:
"I have changed the UVC descriptor to USB descriptor (0X83 IN Endpoint)"
I see that the default AN75779 project makes use of the Endpoint 0x83 for streaming video data and so the descriptors are already set to 0x83.
Also, please let us know if you are trying to develop an application that is UVC compliant. You can also share the UART debug logs so that we can understand the situation better.
Actually i dont have Uart on board. so i am using 16 byte DMA header to send the debug information to host.
if you want that i can send you.
i have tried implemented this solution but still the commit errors and backflow error was coming. There was loss of some frames. so i removed this solution.
In my case, one frame size 10848 bytes and FPGA is sending counter data with speed of 5 MBps at 40 MHz. Still at this slow speed the backflow and commit error is coming and some frames i am getting less than the actual size(short frame less than 10848).
I have discarded initial 1 lac frames coming from FPGA but i did not get any short frame or comit error but when i am using both the interface gpif and usb 3.0 then i am getting comit and backflow error.
How can i remove short frames and the commit and backflow error without data loss.
Can you please increase the Horizontal blanking time as much as you can and try? Also please maintain vertical blanking at a minimum of 300uS.
currently, I am using Frame valid low for 80000 clock cycle (2000uS) and line valid low for 40 clock cycle (1uS).
Now I have increased the Line valid low for 1000 clock cycle(25uS) still some short frames, commit buffer error and buffer overflow are coming.
I have noticed that No. of Prod events is larger than No. of Cons event and their gap (No. of Prod events - No. of Cons event) is increasing with the time.
The black box is the No. of Prod events and the red box is the No. of Cons event.
I have notices that initially i am getting one producer event and one consumer event but after reading some data i stopped getting Cons event(constant at 0x0d5f ) while continuously getting the Prod events.
Because of this issue our all the dma buffer gets full and we start getting Back flow, commit buffer error and short length packet.
In the attached image you can see that we are getting one Consumer event (till 0xd5f) after one producer event then consumer events are constant at 0xd5f while the producer events are incresing and after that we start getting back flow, commit error and short length packet.
in the USBBulksourcesink fimware we have tested our host application can read at speed of 188 MBps.
- Can you please confirm if the parameters of the following API is the same in your firmware: CyU3PDeviceCacheControl (CyTrue, CyFalse, CyFalse); -> If not, please make it as shown and test.
- Is your firmware not UVC compliant? i.e is it a vendor class device?
Thank you for the support,
The parameters of the CyU3PDeviceCacheControl (CyTrue, CyFalse, CyFalse); API is the same in the firmware.
I am neither doing any video streaming in my project nor using video class descriptor.
I am only using UVC design GPIF interface and simple one Many to one DMA to send it to the Bulk In endpoint (usb descriptor like slave fifo).
Taking data from application using XferData API.
i have one question why is xferdata api take different time to transfer data. sometimes xferdata takes less than 1 msec and sometimes it takes very long time (~10-15 m sec)
Please use the attached debug version of the library for your project and test.
Regarding xferdata api:
Xferdata api returns only when entire requested data/ partial USB packet/ ZLP is returned by the device Or if API timeout happens (in which case the transfer is cancelled). In case of Bulk endpoints it also depends on available bandwidth on the USB bus.
The attached library is only a test library and not an official release version.
i have attached this library and tested, still i was getting the same problem.
i have tested the issue on the bulksourcesink project. with streamer app with debug log.
Every read request (BeginDataXfer, WaitForXfer and FinishDataXfer) is not taking equal time. most of the request is taking less than 1 ms but some request is taking 15~16 ms even after reducing timeout per xfer.
Some transfers taking more time - can be because device has no data at that point Or transfer is scheduled late on the USB bus by the Host (as it is bulk)