- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Solved! Go to Solution.
- Labels:
-
USB Superspeed Peripherals
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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:
Please let me know if you have any queries on this.
Jayakrishna
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Jayakrishna
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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:
Please let me know if you have any queries on this.
Jayakrishna
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Rashi