CX3 Image Sensor Interface: 2 extra lines are needed

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

cross mob
user_2884081
Level 4
Level 4
50 replies posted 25 replies posted 10 replies posted

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?

0 Likes
11 Replies
KandlaguntaR_36
Moderator
Moderator
Moderator
25 solutions authored 10 solutions authored 5 solutions authored

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.

0 Likes

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?

0 Likes

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.

0 Likes

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.

0 Likes

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.

0 Likes

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.

0 Likes
lock attach
Attachments are accessible only for community members.

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?

0 Likes

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.

0 Likes

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.

0 Likes

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.

0 Likes

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

0 Likes