Successive MIPI stream validation from CX3

[Philip]

Hello,

We are developing a custom module that features MIPI 2lane, 960 Mbps/lane.
The module has "Embedded Line Data" so we are able to recognize whether the stream is successive or not.
We can get an index for each image and the index should be one of 0, 1, 2, and 3.
However, we only can get images that contain an index of 0 or 2. as below.

Previously, we posted a thread on how to check the DMA buffer to check the image index as below.
https://community.cypress.com/t5/USB-Superspeed-Peripherals/How-to-check-DMA-buffer/m-p/273697#M2638...
We tried to apply the advice from the above thread but it didn't work.
When we applied it, the image flows like below.

Also, the log didn't print out as I expected.
Actually, I want to check the index information, but it was not possible.
So I tested whether it is possible to retrieve data as below.

First, we copied the buffer count to the temp variable that is "ptr_buf_count".



Second, print copied count value.

However, the count value is "0" and even "CB failure" log appears. (Originally, it didn't appear.)
Also, when the image flows, the "Embedded Data Line" is totally abnormal.

(Phase should be one of 0, 1, 2, and 3 / MicroFrame should be 100)

we want to verify that we can receive a successive image.
Thanks.

Regards,
Philip.

[Hemanth]

Hi,

One index number exists for for frame. Please let me know if this is correct. Does this appear at the start of every frame?

If above is true, instead of checking the index number from the firmware, can you let me know if you can take a Wireshark trace and look for what data is coming from the device. In this way, you can can verify the index number.

Regards,

[Philip]

Hello Hemans,
Thanks for your response.

We checked the USB packets using Wireshark.
We don't think it's a host issue anymore.
Because when I captured USB packets using Wireshark, we were able to get images with indexes 0 and 2 only.

Our module features MIPI 2lane, 960 Mbps/lane.
Our settings are below:

#define CX3_UVC_DATA_BUF_SIZE (0x9000) /* DMA Buffer Data Size Used: 24576 Bytes*/
#define CX3_UVC_STREAM_BUF_COUNT (2)

CyU3PMipicsiCfg_t cfgNonUvcVgaNoMclk =
{
CY_U3P_CSI_DF_RGB888, /* CyU3PMipicsiDataFormat_t dataFormat */
2, /* uint8_t numDataLanes */
2, /* uint8_t pllPrd */
99, /* uint16_t pllFbd */
CY_U3P_CSI_PLL_FRS_250_500M, /* CyU3PMipicsiPllClkFrs_t pllFrs */
CY_U3P_CSI_PLL_CLK_DIV_4, /* CyU3PMipicsiPllClkDiv_t csiRxClkDiv */
CY_U3P_CSI_PLL_CLK_DIV_4, /* CyU3PMipicsiPllClkDiv_t parClkDiv */
0, /* uint16_t mClkCtl */
CY_U3P_CSI_PLL_CLK_DIV_2, /* CyU3PMipicsiPllClkDiv_t mClkRefDiv */
1280, /* uint16_t hResolution */
0 /* uint16_t fifoDelay */
};

Could CX3 miss frames because the framerate is too high?
If yes, which part should we check?

Regards,
Philip

[Hemanth]

Hi Philip,

Please provide the snapshot of CX3 Receiver configuration tab of the configuration tool.

Regards,

[Philip]

Hello Hemanth,

Below is the snapshot of CX3 Receiver configuration tab of the configuration tool.

I have one more question.
The resolution of our module is 1280x480 and its bit per depth is 14.
Also, the module has two more embedded line data(EMB).
Therefore, the total resolution is 1280x482.
I think CX3 should send output data(960x482x2 = 925,440) to the host because we use a 24bit data format.
Am I correct?

If correct, it's weird.
When we got a single image without EMB, the output size is 921,600 bytes(960x480x2).
However, we got a single image with EMB, the output size is 925,440 bytes.
Below is a memory map of when we got a single image with EMB.

As above, the horizontal size of the EMB data does not match the image size.
And also, there are dummy data with unknown meaning at the end of every single image.
Are there any rules for EMB data? or do I miss something?

Regards,
Philip

[Hemanth · Accepted solution]

Hi Philip,

Your input data format is 12bit. Hence the expected frame size to be delivered to host is  (1280*482*12)/8 bytes = 925440 bytes.

Please note that CX3 MIPI receiver block does not do any type of data conversion. What RGB24 output format means is that, for each PCLK edge on the GPIF interface, 3 bytes is sent by the MIPI receiver. Since more than 1 pixel data is sent from MIPI receiver in one clock edge (that is, data is packed to 24 bit).

I hope this is clear. Please let me know if you have any questions.

I am not clear why RAW12 is chosen as input format while 14 is bit depth (as mentioned in your last post).

Regards,