RTOS/TDA2P-ACD: CSI2 PHY RESET_DONE is not coming

Adding Clock/Power domain registers:
CM_CAM_CLKSTCTRL = 0x00001702
CM_CAM_STTICDEP = 0x00000030
CM_CAM_VIP1_CLKCTRL = 0x00000001
CM_CAM_VIP2_CLKCTRL = 0x0x00000001
CM_CAM_VIP3_CLKCTRL = 0x00040001
CM_CAM_CSI1_CLKCTRL = 0x00040001
CM_CAM_CSI2_CLKCTRL = 0x00040001
PM_CAM_PWRSTCTRL = 0x00030000
PM_CAM_PWRSTST = 0x00000037

Regards,
James

Hi James,

Can i know the software that you are using?

Also, can you please check on the following
1. CSI2 Clock configuration, the CSI2 clock from the sensor has to match the CSI2/DDR clock configured in CAL.
2. Can you ensure the lane ordering is correct, i.e. clock lane and data lanes are correctly mapped. Also check on the polarity mapping
3. Can you read some register in the sensor to check if frames are indeed being sent

Regards,
Sujith

Hi Sujith,

We are using VSDK 3.02.
1. For CSI2 Clock configuration, camera sensor is outputting 400 MHz which is our default configuration - so, I think there will be no issues in CSI2/DDR clock configuration in CAL but will double check and let you know.
2. Lane ordering and polarity mapping: lane4 - clock, lane1/2/3/5 - data
Confirmed the clock is connected to lane 4
3. Will check sensor registers to confirm if frames are being sent and let you know - we could see the frames are coming from sensor through oscilloscope probing.

In TDA2Px TRM, I could see the comments:
For the CAL_CSI2_COMPLEXIO_CFG_l[29] RESET_DONE bit to be set to
0x1 (reset completed), the external sensor must to be active and sending
the MIPI HS BYTECLK.

Please let me know if you have any other points to check since I could see the clock is coming from sensor - by probing clock lane with the scope.

Regards,
James

Hi Sujith,

Sorry for the confusion.
In my description, I'm following the index from the VSDK 3.02 source code which starts from 1 (not 0).
So, if I follow the indexing in TDA2Px TRM: clock- lane3, data- lane0/1/2/4.

Regards,
James

Hi James,

OK, i understand. Which sensor / camera module are you using?
Also, please ensure to start video streaming on the camera module just before you start CAL/Reception on TDA2Px.

Please cross check the CSI2 Clock from the sensor.

Regards,
Sujith

Hi Sujith,

It's AR0231 2M sensor.
Will check the timing and let you know but what could be a best timing to start video streaming when you say just before CAL?
Do you expect any problems if we start streaming much earlier than expected?

Regards,
James

Hi James,

MIPI performs a initial handshake before switching to high speed transmission mode. Once the termination is enabled on the lanes, there is definite timeout before switching to high-speed transmission mode. (Standard DPHY / MIPI sequence)

Please refer single channel CAL/CSI2 based usecases. The CAL is configured and before the function call to start reception, the sensor would be programmed and transmission enabled and CAL / CSI2 receiver is started.

Please refer file \apps\src\rtos\usecases\iss_capture_isp_simcop_display\chains_issIspSimcop_Display.c function chains_issIspSimcop_Display_StartApp ().

Function appStartIssSensorSerDes () Starts the sensor and function call chains_issIspSimcop_Display_Start () starts reception via CSI2 / Capture Link.

Regards,
Sujith

Hi Sujith,

I'm running chains_csi2CalMultiCam_View usecase and in chains_csi2CalMultiCam_View_StartApp(), camera sensor starts video streaming before chains_csi2CalMultiCam_View_Start() gets called but RESET_DONE is not coming yet in CAL_CSI2_COMPLEXIO_CFG register.

Regards,
James

Hi James,

If you have set the Capture Link parameters as per the lanes connected and CSI2 clock provided by the camera. It should have worked. Can you please check if the sensor configuration is working with any other board.

Also, if you have camera module/EVM that is supported by VisionSDK, you could ensure EVM is fine.

Regards,
Sujith

Hi Sujith,

I tested the use case on TDA2Px EVM with Fusion Kit (OV2775 sensor) and could see the RESETDONECTRLCLK (bit 29) was set first in REG1 register and after that, as soon as BYTECLK was received from sensor (through deserializer) RESETDONERXBYTECLK (bit 28) was set (REG1: 0xE002E116 --> 0xF002E116).

But on the customer board, REG1 register value is 0xC002E116 which means CTRLCLK is not provided to CSI2 PHY from PRCM.

The clock tree is: CTRLCLK <-- LVDSRX_96M_GFCLK <-- FUNC_96M_FCLK <-- FUNC_192M_CLK <-- DPLL_PER [CLKOUTX2_M2].

So I checked below registers on the customer board but could not see any suspicious points:

1. CM_CLKMODE_DPLL_PER(0x4A00 8140) = 0x07
     DPLL_EN = 7 (Enables the DPLL in Lock mode)
2. CM_DIV_M2_DPLL_PER(0x4A00 8150) = 0x0804
    CLKX2ST = 1 (The clock output is enabled)
    DIVHS = 4 (M2)
3. CM_CLKSEL_DPLL_PER(0x4A00 814C) = 0x6004
    DPLL_MULT = 96
    DPLL_DIV = 4

Could you let me know from what points/registers should I check to confirm if CTRLCLK is provided properly from  PRCM?

FYI, CTRLCLK is enabled in Control Module as you  can see in my first posting.

CTRL_CORE_CONTROL_CSI (0x4A00 26DC) = 0xF8000900

Regards,

James

Hi James,

Once the clock from the CSI2 source is detected and locked on, the byte clock is generated. In this case, i doubt the de-serailizer configuration.

Can you please check if you could operate de-serilizer in "continuous clock mode"

Regards, Sujith

Hi Sujith,

Yes, that's for BYTECLK which is coming from camera sensor (externally) but I'm not sure why the CTRLCLK which is the control clock for CSI2 PHY module coming from PRCM is not set properly on customer board.

Regards,
James