- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'm using the CX3 device as an interface between a Sony IMX219 image sensor and the PC via USB3.0.
After using the Denebola kit, I was able to create a custom board and use the Sony sensor and not the Omnivision one used in the Denebola.
Right now, the custom board works with 4 MIPI lanes.
I can configure my sensor through I2C to the configuration I want. With the Cypress Mipi Configuration Tool I can obtain the MIPI block parameters to make it work.
Input parameters:
- THS-Prepare: 60
- THS-Zero: 250
- Input video format: RAW8
- Output video format: 16-bit
- Data lanes: 4
- CSI Clock: 480MHz
- H-Active: 1638
- H-Blanking: 1810
- V-Active: 1232
- V-Blanking: 50
- Frame rate: 93
Output parameters:
CyU3PMipicsiCfg_t cfgUvcFullFOVx2Mipi4Raw8 = {
CY_U3P_CSI_DF_RGB565_2, /* dataFormat */
4, /* numDataLanes */
2, /* pllPrd */
123, /* pllFbd */
CY_U3P_CSI_PLL_FRS_250_500M, /* pllFrs */
CY_U3P_CSI_PLL_CLK_DIV_4, /* csiRxClkDiv */
CY_U3P_CSI_PLL_CLK_DIV_4, /* parClkDiv */
0, /* mclkCtl */
CY_U3P_CSI_PLL_CLK_DIV_2, /* mClkRefDiv */
1638, /* hResolution */
0 /* fifoDelay */
};
PHY Delay is 18.
GPIF Bus width is 16 bits.
I have a debugging system and can confirm that the GPIF is getting the bytes correctly.
However, in order to see the video stream on a viewer (e-CamVIEW), I need to tell the PC 2 extra lines will be sent.
Probe control size in bytes is set to 1638x1234, instead of 1638x1232.
The frame descriptor is width=819, height=1234, 16bpp.
This way, the viewer shows the stream, but if I set the probe control and frame descriptor to the real size (1638x1232) it doesn't work.
This has happened since I first got the system working, with all resolutions: 1640x1232, 1638x1232, 1080p, 720p, VGA, 820x616.
Why is this happening?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If you do not add the extra two lines, what is happening your case.
Please confirm what is the length of the frame received by the host (1638x1232 bytes or 1638x1234 bytes)
You can see that the frame size in USB trace.
Can you please measure the frame size in DMA Callback (based on your partial buffer)?
If your frame size is 1638x1232 and RAW 8, your frame size would be 1638x1232*1 bytes. Is this matching with value obtained in DMA Callback? Otherwise, please mention the frame size as per DMA callback.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
By checking the USB trace I can confirm that the PC host is receiving 820x618 bytes whether I set probe control and frame descriptor to 820x616 or 820x618, it doesn't matter.
My debugging system outputs the sum of the DmaBuffer.count in every DMA callback, and resets the value every frame. The number of bytes I'm getting with the 820x616 resolution (which works on e-CAMView) is 0x794BC instead of 0x7BB88 (820x618), which is a little bit less than the expected number of bytes.
Do you need to take a look at the code or maybe have a call?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In the USB Trace, you will see header information(12 bytes per buffer) along with the video data for every buffer. Have you removed it
Please let me know the dma buffer size and number of buffers per frame.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The header is still there, and it even changes the frame ID, the EOF bits.
The DMA buffer is 0x5FD0=24528, and the pack has 24528+12+4 bytes for header and footer. I can confirm I am getting 21 packs (20 + 1 partial), wich completes the amount of bytes.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi KandlaguntaR_36,
We have been stuck with this problem and other issues for weeks now, and I can't get a good solution or communication. I thank you for helping, but I feel like Cypress is not giving as much support as needed and expected.
Can we please schedule a Skype or Hangouts call so we can talk about the issues I am having and try to solve them? It would help us a lot.
Thanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It seems that you are debugging the 820x616 resolution with RAW 8 bytes per pixel. Please confirm.
What is the size of the partial buffer you are receiving?
Please provide uvc.c file for review.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, I am debugging the 820x616 resolution (actually 820x618 for the PC to work) because it is working with most viewers.
The partial buffer I am getting is 0x3F54 (16212).
The only difference between the uvc.c I am using and the one created by the Cypress MIPI configuration tool is that the GPIF size (ES_UVC_SS_DATA_BUF_SIZE) is set to 0x5FF0 by default, I set it to 0x5FD0 for 24b, but the file created uses 0x8FD0. Any idea why is this?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
After changing the UVC Video Streaming format from RGB565 to YUY2, the higher resolution (1638x1234) works too, so now I'm seeing both of them. They still have the 2 extra lines.
I can confirm with an USB analyzer that the number of bytes received by PC are 1638x1234 and 820x618 as expected (2 extra lines in both).
From internal debugging, the DMA callback (esUVCUvcAppDmaCallback) sends:
- 1638x1234: 83 packs, 82 of them with the max size (0x5FD0) and the last one with 9996 (0x270C) bytes.
- 820x618: 21 packs, 20 of them with the max size (0x5FD0) and the last one with 16200 (0x3F48) bytes.
EDIT: I was using 1638x1234 and 820x618, and the higher resolution didn't work until I got it to 1640x1234 because the line sent to the PC was 819 px, and YUY2 expects an even number.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
As per the debug prints in DMA Callback and UVC data in the trace, you are receiving 1638*1234 = 2021292 bytes.
i.e. 82*0x5FD0 (full buffer) + 0x270C (partial buffer) = 1638*1234 = 2021292 bytes
This confirmd that CX3 is receiving 1638X1234 bytes per frame instead 1638x1232 bytes and transferring the same amount of bytes to the PC.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, I can see that. Right now it is working at 1640x1234 and 820x618, and in both cases there are two extra lines which can be seen in the DMA callback, which means the MIPI block is reading those 2 extra lines. The thing is the sensor is set to 1640x1232 and 820x616, and the 2 extra lines are black (zeros), so maybe the MIPI block is reading it wrong.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Here, the sensor is sending extra data equalent to 2 horizontal line size. We can discard the two lines, if the width of the data is equal to a buffer size. Otherwise, you need to take care of them in the host application.
Regards,
Sridhar