CX3 UVC Stream only works with large hblank

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

cross mob
samkay
Level 1
Level 1
First reply posted First question asked Welcome!

Hi,

I have the following settings working:

Sensor: RAW8 , 1280x800, 2 lanes, V-blank=30 lines, V-blank=400
MIPI settings: CY_U3P_CSI_DF_RAW8
GPIF: 8-bit
PLL Pixel Clock output settings: 100MHz (max)
UVC Settings: Works fine using {8bbp,1280 width} on Linux hosts or {16bpp,640 width } on Windows hosts

Streaming works fine when the sensor's H-Blank set to 400 pixels (gives 70fps).  However, as soon as I try to reduce it, streaming stops and I guess DMA overflow happens.

We are way below the bandwidth USB requirements and we should easily get 90fps (~90MBps).  How can we achieve that?

Thanks

 

 

 

 

 

 

 

 

0 Likes
1 Solution

Hello Sam,

The API CyU3PDmaMultiChannelCommitBuffer () usually fails with error code 71 when the host is slow in issuing IN tokens to clear the DMA buffers filled b CX3. We recommend to use a greater line blanking to avoid this issue. This is already mentioned in the following KBA:
https://community.infineon.com/t5/Knowledge-Base-Articles/Handling-Commit-Buffer-Failures-Occurred-d...

Can you please try to configure CX3 to pack the incoming data into 16 bits and check if you are still facing this issue? Please refer to the following KBA to understand how to pack the incoming data into 16 bits:

https://community.infineon.com/t5/Knowledge-Base-Articles/Streaming-RAW10-Format-Input-Data-to-16-24...

Please let me know if you have any queries on this.

Best Regards,
Jayakrishna

View solution in original post

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

Hello,

Please let us know the following so that we can debug the issue faster:

1. What is the USB connection speed? Is it USB 3.0 or USB 2.0?

2. Please share the snapshot of the MIPI configuration utility for us to check.

3. Please share the UART debug logs for us to review. This is to check if the issue is caused by the failure of the  API CyU3PDmaMultiChannelCommitBuffer () with error code 71 or not.

4. Please try reducing V-Blanking too when the H-Blanking is reduced. While doing this, please ensure that the V-Blanking time is greater than or equal to 500uS.

Best Regards,
Jayakrishna
0 Likes
lock attach
Attachments are accessible only for community members.
samkay
Level 1
Level 1
First reply posted First question asked Welcome!

Hi Jayakrishna,

1. This is USB 3.0
2. Screenshots attached
3. If I start from a hard-reset, I usually get no error and the reset event (CX3_DMA_RESET_EVENT) is not triggered, I just get wrong buffer sizes and nothing is displayed:

-Working H-Blank=400:
 Prod = 27 Cons = 27 Prtl_Sz = 29968 Frm_Cnt = 388 Frm_Sz = 1024000 B
-Not working h-blank=300:
 Prod = 20 Cons = 20 Prtl_Sz = 31680 Frm_Cnt = 2 Frm_Sz = 768000 B

However, if I change the blanking (from 400->300) during streaming, then I indeed get the 71 DMA error and CB failure (printing is done outside the CB):
  DMA_RESET: DMACommit_status=71
  CB failure

I am using the default buffer sizes, and SDK 1.3.4

4. The blank is at a minimum of 30 lines. Smaller gives the same result

 

Thanks!
Sam

 

 

0 Likes

Hello Sam,

The API CyU3PDmaMultiChannelCommitBuffer () usually fails with error code 71 when the host is slow in issuing IN tokens to clear the DMA buffers filled b CX3. We recommend to use a greater line blanking to avoid this issue. This is already mentioned in the following KBA:
https://community.infineon.com/t5/Knowledge-Base-Articles/Handling-Commit-Buffer-Failures-Occurred-d...

Can you please try to configure CX3 to pack the incoming data into 16 bits and check if you are still facing this issue? Please refer to the following KBA to understand how to pack the incoming data into 16 bits:

https://community.infineon.com/t5/Knowledge-Base-Articles/Streaming-RAW10-Format-Input-Data-to-16-24...

Please let me know if you have any queries on this.

Best Regards,
Jayakrishna
0 Likes
samkay
Level 1
Level 1
First reply posted First question asked Welcome!

Thanks Jayakrishna,

I tried to overclock the GPIF by changing the parClkDiv to get a total of 200MHz, instead of the 100MHz maximum, and that did improve the timing and I can run it much with a much lower hblank and effectively double the fps. This proves that the problem is unrelated to the USB host consuming the packets.

I then tried to use 16-bit data packing (MIPI settings to CY_U3P_CSI_DF_RGB565_2 and GPIF at 16-bit) and I can indeed reduce the H-blank to around 150 but not less than that (ideally it would be around 20).

Thanks

Sam

 

 

 

 

0 Likes
Rashi_Vatsa
Moderator
Moderator
Moderator
5 likes given 500 solutions authored 1000 replies posted

Hi Sam,

As might be aware that GPIF II block of CX3 supports maximum clock of 100 MHz . We do not recommend to use 200 MHz PCLK.

I then tried to use 16-bit data packing (MIPI settings to CY_U3P_CSI_DF_RGB565_2 and GPIF at 16-bit) and I can indeed reduce the H-blank to around 150 but not less than that (ideally it would be around 20).

>> Please let us know the frame rate (fps) at which you want to stream the video. 

Regards,
Rashi
0 Likes