1. LP to HS transition is not necessary to CLK.
2. If there is no VSYNC High from MIPI block of CX3, the GPIF stuck at state 2 itself. Please probe
G6 HSYNC_test and H5 VSYNC_test pins for HSYNC and VSYNC signals. There is no APIs as you requested.
Note that the VSYNC goes high when there is Frame Start on the MIPI lane and goes Low when there is Frame End on the MIPI Lane.
3. If you change any parameters in the Transmitter side, enter the same in MIPI configuration tool then use the MIPI configuration generated by it.
Have you checked whether there is any MIPI errors using CyU3PMipicsiGetErrors?
Please refer CX3_ERROR_THREAD_ENABLE MACRO in OV5640 example firmware to monitor the MIPI errors.
Thanks for the information,
I probe the VSYNC_test, HSYNC_test and PCLK again , VSYNC_test and HSYNC_test are not toggled. The PCLK is 80Mhz, same as the MIPI receiver confguraion I gave to CX3.
And I enable the CX3_ERROR_THREAD_ENABLE to print error count every 5 seconds, all of the error counts are zeros.
When I enable CX3_ERROR_THREAD_ENABLE I also change the CyU3PEventGet() wait Option in CyCx3UvcAppThread_Entry() function.
To made it do CyU3PEventGet() every 5 seconds instead of doing busy waiting the whole time.
Also I made an experiment to test if the GPIF II indeed is not receiving anything.
I call the GPIF II call back function manually, 3 seconds after receiving SET_CUR request.
The GPIF --> DMA --> UVC workflow works perfectly and sends nothing out as I expected.
Any Suggestions on what to do next?
Feels like it's still a configuration problem but I'm not too sure.
I'm still using the MIPI receiver configuration you gave me, since the configs generated by Eclipse didn't even trigger the MIPI HS termination.
I have entered your settings in the MIPI tool as follows and obtain MIPI configuration.
The MIPI Config. parameters are as follows:
CyU3PMipicsiCfg_t null_UYVY_Resolution0 =
CY_U3P_CSI_DF_YUV422_8_2, /* CyU3PMipicsiDataFormat_t dataFormat */
4, /* uint8_t numDataLanes */
2, /* uint8_t pllPrd */
99, /* uint16_t pllFbd */
CY_U3P_CSI_PLL_FRS_125_250M, /* CyU3PMipicsiPllClkFrs_t pllFrs */
CY_U3P_CSI_PLL_CLK_DIV_2, /* CyU3PMipicsiPllClkDiv_t csiRxClkDiv */
CY_U3P_CSI_PLL_CLK_DIV_2, /* CyU3PMipicsiPllClkDiv_t parClkDiv */
0, /* uint16_t mClkCtl */
CY_U3P_CSI_PLL_CLK_DIV_2, /* CyU3PMipicsiPllClkDiv_t mClkRefDiv */
1920, /* uint16_t hResolution */
80 /* uint16_t fifoDelay */
We can see there is no change in above parameters.
Since you changed the THS Zero to 472 ns, the THS Settle value i.e PHY Delay Value should change to 24 from 8.
You can see this number in the right bottom corner under CX3 MIPI Interface Configuration.
As per the above responses from you, the MIPI configuration is fine and there are no MIPI errors.
Can you please check whether the ISP is streaming data correctly (MIPI Transmitter settings)? Hence, the CX3 MIPI can decode accordingly.
Please let me know the packet format of MIPI Transmitter.
Please check whether the connection between MIPI Receiver and MIPI Transmitter (ISP) are correct for all four data lanes and clock lane.
You told that there are terminations. However, check once again for all the lanes.
Thanks for the notice,
I checked four lanes again, found that one of our lane had some problem.
And now I'm able to get in to DMA Call Back event, but the producer callback failed with Error code = 0x45.
Sorry for having this messy debug message, I've added tons of things myself.
Beside the error 0x45,
Why does the DMA callback have been triggered, while GPIF II seems not to be triggered at all?
I have this question is because I got a debug print message in GPIF II call back function like this:
CyU3PDebugPrint (4,"\n\r*********************GPIF Interrupt*************************");
And I assume that the print out message should be happening before "********DMA Call Back*******" message.
While it never shows up.
It is good to know that the issue on the data lanes is solved.
Please probe VSYNC and HSYNC now and share the HSYNC High and Low; VSYNC high and low timings.
Answering other queries:
1. Note that the GPIF interrupt comes when there is Frame End.
In the frame end state of the GPIF state machine, we have set Interrupt CPU action. This triggers the GPIFCB function. Hence, DMA Callback event can come irrespective of GPIFCB.
2. Please remove the debug prints in Callback functions. This may block normal functionality.
Put a flag and print in the infinite for loop running in Main Thread.
3. Please share the snippet that printed 0x45 (CY_U3P_ERROR_TIMEOUT = Timeout on relevant operation). This error comes when there is a timeout on relevant operation
I hope that you might have referred AN75779 App. Note to understand the UVC application firmware. If not, please refer.
When I disable the print debug message.
The video finally came out.
Thanks for all the support !!
You're the best