- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
We are trying a new configuration for our sensor (we already have a working configuration). With this new configuration we want to change the data format (from RAW10 with unused bits to RGB888).
the only error we get is on host side, we do not receive expected amount of data per service interval.
We do not have any mipi errors, but we take a look to Hsync and Vsync.
picture is attached. Vsync and Hsync are output of CX3 and CLK_MIPI and D0_MIPI are taken between sensor and CX3 (differential probe)
We can see glitches in Hsync.
Is any one have any idea of what to test or try ?
Thank you,
Best regards,
Benjamin.
Solved! Go to Solution.
- Tags:
- cx3 mipi csi-2
- hsync
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Benjamin,
>> Is there a maximum PCLK value for a specific value of the MIPI clock ? (and setting PCLK to the max (100MHz) is not a good idea).
The GPIF II PCLK works up to 100 MHz. Here this PCLK is driven by MIPI block of CX3.
If you are using 19.2 MHz Crystal to CX3, the maximum PCLK at which GPIF functions is 96 MHz.
In order to make GPIF II to work at 100 MHz (> 96 MHz), we need to do the following change in firmware.
clockConfig.setSysClk400 = CyTrue;
Once you do the above change, you can set the MIPI PCLK to previous value 98.6 MHz and check the functionality in 24-bit case.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Benjamin,
Can you please the screen shot of CX3 MIPI Configuration tool in which we can see Image Sensor parameters and MIPI Receiver parameters?
Regards,
Sridhar
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Sridhar,
Please find enclosed the MIPI configuration we use.
/* OV12895_1080p_RAW10_1080p : */
CyU3PMipicsiCfg_t OV12895_1080p_RAW10_1080p =
{
CY_U3P_CSI_DF_RGB888, /* CyU3PMipicsiDataFormat_t dataFormat */
4, /* uint8_t numDataLanes */
0, /* uint8_t pllPrd */
40, /* uint16_t pllFbd */
CY_U3P_CSI_PLL_FRS_500_1000M, /* CyU3PMipicsiPllClkFrs_t pllFrs */
CY_U3P_CSI_PLL_CLK_DIV_8, /* CyU3PMipicsiPllClkDiv_t csiRxClkDiv */
CY_U3P_CSI_PLL_CLK_DIV_8, /* CyU3PMipicsiPllClkDiv_t parClkDiv */
0, /* uint16_t mClkCtl */
CY_U3P_CSI_PLL_CLK_DIV_2, /* CyU3PMipicsiPllClkDiv_t mClkRefDiv */
800, /* uint16_t hResolution */
1 /* uint16_t fifoDelay */
};
and PhyTime delay:
l_t_Status = CyU3PMipicsiSetPhyTimeDelay(0, 0x0A);
and GpifLoad:
l_t_Status = CyU3PMipicsiGpifLoad(CY_U3P_MIPICSI_BUS_24, 24384);
We use the following DMA configuration:
l_t_DmaCfg.size = 24576;
l_t_DmaCfg.count = 4;
l_t_DmaCfg.validSckCount = 2;
l_t_DmaCfg.prodSckId[0] = sgm_k_PRODUCER_PPORT_SOCKET_0;
l_t_DmaCfg.prodSckId[1] = sgm_k_PRODUCER_PPORT_SOCKET_1;
l_t_DmaCfg.consSckId[0] = sgm_k_EP_VIDEO_CONS_SOCKET;
l_t_DmaCfg.dmaMode = CY_U3P_DMA_MODE_BYTE;
l_t_DmaCfg.notification = CY_U3P_DMA_CB_PROD_EVENT | CY_U3P_DMA_CB_CONS_EVENT;
l_t_DmaCfg.cb = sgm_cb_ManageStream;
l_t_DmaCfg.prodHeader = 192;
l_t_DmaCfg.prodFooter = 0;
l_t_DmaCfg.consHeader = 0;
l_t_DmaCfg.prodAvailCount = 0;
Thank you.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Benjamin,
The MIPI configuration is fine.
Can you please try with _t_Status = CyU3PMipicsiSetPhyTimeDelay(1, 0x0B): Change first argument from 0 to 1, second argument from 0x0A to 0x0B?
Regards,
Sridhar
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sridhar,
We try these values, same behaviour (No mipi errors and glitches, and no stream).
We did one more test:
We try it in a 16bits mode and it works fine.
Data format set to RAW10 and Hresolution to 1920in mipi cfg.
and CY_U3P_MIPICSI_BUS_16 in CyU3PMipicsiGpifLoad.
So we start to think we miss something in the change from 16bits to 24bits.
Thank you,
Best regards,
Benjamin.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Benjamin,
Can you please set the system clock to 400 MHz mode and test?
/* Initialize the device */
CyU3PSysClockConfig_t clockConfig;
clockConfig.setSysClk400 = CyTrue;
clockConfig.cpuClkDiv = 2;
clockConfig.dmaClkDiv = 2;
clockConfig.mmioClkDiv = 2;
clockConfig.useStandbyClk = CyFalse;
clockConfig.clkSrc = CY_U3P_SYS_CLK;
status = CyU3PDeviceInit (&clockConfig);
if (status != CY_U3P_SUCCESS)
{
goto handle_fatal_error;
}
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Sridhar,
We found something we don't understand.
We tried to slow down the Parallel Output Clock (PCLK), and glitches in Hsync disappears when we set PCLK slower than 80MHz.
For the moment, we don't have any more issues but we do have a question:
Is there a maximum PCLK value for a specific value of the MIPI clock ? (and setting PCLK to the max (100MHz) is not a good idea).
Benjamin.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Benjamin,
>> Is there a maximum PCLK value for a specific value of the MIPI clock ? (and setting PCLK to the max (100MHz) is not a good idea).
The GPIF II PCLK works up to 100 MHz. Here this PCLK is driven by MIPI block of CX3.
If you are using 19.2 MHz Crystal to CX3, the maximum PCLK at which GPIF functions is 96 MHz.
In order to make GPIF II to work at 100 MHz (> 96 MHz), we need to do the following change in firmware.
clockConfig.setSysClk400 = CyTrue;
Once you do the above change, you can set the MIPI PCLK to previous value 98.6 MHz and check the functionality in 24-bit case.