commit error and back flow error in UVC AN75779

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
AvC_4590276
Level 1
Level 1

Hi Readers,


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.

Thanks

0 Likes
13 Replies
JayakrishnaT_76
Moderator
Moderator
Moderator
First question asked 1000 replies posted 750 replies posted

Hello,

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.

Best Regards,

Jayakrishna

Best Regards,
Jayakrishna
0 Likes

hi jayakrishna,
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.

0 Likes
Hemanth
Moderator
Moderator
Moderator
First like given First question asked 750 replies posted

Hi,

Can you please let me know if the follow KBA content is already implemented in your firmware?

Invalid Sequence Error in Multi-Channel Commit Buffer - KBA218830

Regards,

Hemanth

Hemanth
0 Likes

Hi,

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.

0 Likes
Hemanth
Moderator
Moderator
Moderator
First like given First question asked 750 replies posted

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.

Regards,

Hemanth

Hemanth
0 Likes

Hi Hemanth,


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.

0 Likes

Untitled.png

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.

0 Likes
Hemanth
Moderator
Moderator
Moderator
First like given First question asked 750 replies posted

Hi,

- 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?

Regards,

Hemanth

Hemanth
0 Likes

Hi Hemanth,

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.

0 Likes

Hii ,

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)

0 Likes
lock attach
Attachments are accessible only for community members.
Hemanth
Moderator
Moderator
Moderator
First like given First question asked 750 replies posted

Hi,

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.

Regards,

Hemanth

Clarification:

The attached library is only a test library and not an official release version.

Hemanth
0 Likes

Hi,

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.

streamer.pngtimetakenperxfer.png

0 Likes
Hemanth
Moderator
Moderator
Moderator
First like given First question asked 750 replies posted

Hi,

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)

Regards,

Hemanth

Hemanth
0 Likes