CX3 CSI clock validation

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

cross mob
lock attach
Attachments are accessible only for community members.
leda_289486
Level 5
Level 5
10 sign-ins 5 sign-ins 100 replies posted

Hi,

following a former question, I'd like to know if there is some register(s) to check whether the CSI clock from sensor is correct for CX3 or not. For now we have programmed an 300 MHz clock, and I made a screen copy of what we get at oscilloscope for one of the differential clock signal. Frequency is respected and the other differential lane clock is as expected.

However I get no feedback from dma nor for LV and FV test signals (available).

If I dump the result from CyU3PMipicsiGetErrors function, here is what we get also when we comute AppStart/AppStop.

Would it be possible to have more information regarding these errors ?

Best Regards.

0 Likes
1 Solution

issue was initiated because sensor sent frame + extra data. these extra data size was not a multiple of 3 and that could not be corrected after.

We manage to avoid the send of the extra data and after that, all sent lines have a size multiple of 3 and that's it.

View solution in original post

0 Likes
27 Replies
leda_289486
Level 5
Level 5
10 sign-ins 5 sign-ins 100 replies posted

Hi,

For examining how errors counters change I've implemented a dedicated thread to display error counts every 5s.

What I have noticed is that these 3 values are changing :

mdlErrCnt, recSyncErrCnt and unrSyncErrCnt.

The other values are null.

Could you please indicate what does it mean exactly and what is suspected to create this condition (sensor bad configuration ? sensor bad clock identification ?)

In parallel of this, I"ve a question regarding the MIPI_RESET pin on CX3. What exactly is performed at start with this pin ?

Thank you for your help,

0 Likes

Lebrun,

Can you please share the screen shots of the MIPI Receiver configuration Tab for reference?

Let us know whether the sensor is operating the clock in continuous mode or gated MIPI mode.

(The clock is continuous clock mode: LP-HS transition only happen once, clock does not switch back to LP between lines or frames).

Refer this thread: https://community.cypress.com/message/163142?et=watches.email.thread#163142

The MIPI_RESET pin should be pulled down with a resistor.

In CyU3PMipicsiInit API, this pin will be pulled low an pulled high. You can refer the source code at cyu3mipicsi.c.

Regards,

Sridhar

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

Hi,

the clock is in continuous mode.

here is include the resulting file from cx3 configuration tool. No error with this set inside the configuration tool. We have discussed of this as a case with Hemanth before.

Regarding MIPI_RESET : what is the use of setting low at start then high ?

I guess it is indeed the GPIO[27] that is driven inside the mipiinit procedure. What is the difference if we drive this pin low at start using an Override function ?

I'll check out your reference link.

Thank you for your help,

Best regards

0 Likes

Please refer this and implement the same.

Question: Will CX3 support “Continuous MIPI clock” and “gated MIPI clock” modes?

Answer: Yes. CX3 support both clock modes. The CX3 chip recognizes the CSI clock by MIPI CSI LP to HS mode transition at the beginning. Therefore, after finishing the initialization of the CX3 MIPI bridge, the CSI clock must transit from LP to HS mode. You should use the following sequence in firmware if you are using the sensor in “continuous clock mode.”

  • Upon receiving the Set_Cur (Commit control) request from the host, perform a MIPI reset (CyU3PMipicsiReset() with the reset type as Hard reset ).
  • Initialize the MIPI bridge (CyU3PMipicsiInit () )
  • Set the MIPI interface parameters (CyU3PMipicsiSetIntfParams ()).
  • Release the reset of the sensor (XRST) (CyU3PMipicsiSetSensorControl() ).
  • Configure the sensor.
0 Likes

>> Regarding MIPI_RESET : what is the use of setting low at start then high ?

This resets the MIPI Block.

0 Likes

We are following your sequence in firmware but we still have same errors.

I understand that it resets the mipi block but in the library code of MipiReset"hardware", the MIPI_RESET pin is considered as gpio 27. It is simply driven low then high as an  overrided gpio.

Now, what is the difference between the pin drive (low/high) through gpio commands and the initial setting of mipi_reset pin through the external resistor ?

Thank you for your help,

Best Regards,

0 Likes

Lebrun,

Initially this pin will be set to low by external resistor (Pulling Down). When we call MIPICSIInit API, this will be pulled high.

If needed, we can use MIPICSIRESET API to reset the MIPI block.

Can you please probe the LV, FV and PCLK on TEST pins provided and share the values here?

Let me know what is the resolution that you are trying to stream now.

0 Likes

srdr,

Ok if I fully understand, if MIPICSIReset api is performed (with hardware option) and return status is ok, we can consider that this is ok for this part ?

I have probed LV and FV, there is no signal present. But I've read in another discussion that when errors are returned with mipicsiGetErrors this can prevent FV and LV to toggle correctly : so I guess we can be in this situation...

Regarding pclk, the pin is not available directly. If i understand configuration tool, this pck signal is derived from 19.2 Mhz REF_CLK, so it is not reallly dependant from sensor output ?

The resolution we are trying to stream is for now 960x540, 10 bits/pixel, 30 fps. It should be easy to fulfil the requirements in usb3 normally. And also the data rate is not that high.

Best Regards.

0 Likes

Srdr,

have you checked out the clock signal we have copy on screenshot of oscillioscope (tek0001.png) ?

I'd like to have your knowledge to estimate if current amplitude for example is correct for a mipi csi2 clock ?

It is not obvious to see in one frame but jitter seems to be quite small also.

Thank you for your help,

Best Regards,

0 Likes

srdr,

Is there a cypress document to understand the exact meaning of "MdlErrCnt", "recSyncErrCnt" and "unSyncErrCnt" ?

For now, with my 5s thread error examination, only these values are not nulled.

What is a "recoverable" sync error count and its counterpart an "non recoverable one" ?

For now situation is this :

all mipicsi functions return a status code of CY_U3P_SUCCESS

the configuration tool returns no error while creating the files.

the first resolution is 960x540, 10 bits, 30 fps and is not very resource dependant for usb3

CSI clock is 300 Mhz, normally correct (=> we ask you if it is)

sensor access is ok (we can read/write registers normally)

configuration of sensor is the one expected, correctly updated at each resolution

the sequence used is the one of .13  application note for continous clockn with no error returns in sequence.

XREST is perfoming correctly

but no FV / no LV signal on test pins of cX3. PCLK no available (normally programmed to 99.2 Mhz)

thank you for your help,

Best Regards,

0 Likes

srdr,

with the sensor used, the data for each frame are sent in 2 operations. First it sends "inforrmation data" that have a specific fixed length, typically 180 bytes, ie not dividible by 8 and then it sends "frame data" with the correct defined line size.

For example with the resolution we talked about :

960 pixels of 10 bits/ pixels => 960*10/8 = 1200 bytes transmitted /line. so this is the "word count" and resolution set via Setintf function is 400 (1200/3). Is this correct ?

However, sensor always sends the batch of180 bytes data first : how it is managed through CX3 mipi decoder ? because it obviously generates a "bad line length" error.

These "informative"' data have a packet data type specific, different from "frame data". Is there an option in CX3 to "reject" or "filter" such specific data types ? or to consider line valid even if it is not the expected data line (but here still dividible by 3).

Thank you for your help,

Best regards,

0 Likes

parallel question is how LV signal is generated from the csi2 data : does it check that  receieve length is the one expected or doest it simply generate a signal between the header/footer or only with exact line length ? (== WordCount filled fromhResolution value)

Best Regards

0 Likes

In general LV and FV are derived from the MIPI CSI-2 data.

Here is the snap shot that describes how VSYNC (FV) and HSYNC (LV) are derived from the MIPI CSI-2 data. Source: MIPI Alliance Specification for CSI-2 Spec. The terminology is changed to VVALID and HVALID instead FV and LV respectively.

pastedImage_0.png

The MIPI configuration that we provide will help the MIPI Block on CX3 to generate the clocks, fifo delay, PHY Delay and etc. that are needed to to steam the data provided by the sensor.

In your case, the sensor is providing some additional data (180 bytes before actual video data) apart from the Horizontal Line data. Hence, the MIPI block should generate FV and LV for this 180 bytes too. This can be seen on FV and LV timing diagram.

But in your case, there is no FV and LV. I suspect that there is something wrong in the MIPI configuration.

Can you please confirm whether you have set the PHY Delay using CyU3PMipicsiSetPhyTimeDelay API in the firmware?

Also share the screen shots of CX3 Receiver Configuration Tab of configuration tool.

0 Likes

srdr,

thank you for this information.

First I confirm I use the cyU3PMipicsiSetPhyTimeDelay api in firmware, here is the related code and sequencement :

void MipiForceTm(void)

{

uint8_t res;

uint8_t tm = 1;

uint8_t delay = 5;

CyU3PMipicsiSleep();

res = CyU3PMipicsiSetPhyTimeDelay(tm,delay);

CyU3PDebugPrint (4, "SetPhyTimeDelay %d-%d res=%d\r\n",tm,delay,res);

CyU3PMipicsiWakeup();

}

the range of correct "delay" value is quite reduced. 5 is OK, res is CY_U3P_SUCCESS always.

void MipicsiSensorReset(CyBool_t mode)

{

uint8_t ret;

ret = CyU3PMipicsiSetSensorControl(CY_U3P_CSI_IO_XRES,mode);

CyU3PDebugPrint (4, "Sensor Reset through XCLR mode=%d ret=%d\r\n",mode,ret);

}

This is the sequence explained I guess in .13 of application note : (example for 4K)

/* Write 4KSettings */

case 0x00:

  status = CyU3PMipicsiSetIntfParams (&IMX274_RAW10_4K, CyTrue);

  CyU3PDebugPrint (4, "\n\rUSBStpCB:SetIntfParams(4K) SS1 Err = 0x%x\r\n", status);

  MipiForceTm();

  MipicsiSensorReset(CyTrue);

  CyU3PThreadSleep(5);

  CyCx3_ImageSensor_Set_4KDL ();

break;

here are following the requested screen copies.

My worry is regarding the resolution values. These values are the pixels output size from sensor. As it is a raw10 / pixels sensor, i should have programmed as "hresolution" :

3840 pixels => 4800 bytes => 1600 as Hresolution (WordCount = 4800)

1920 pixels => 2400 bytes => 800 as Hresolution  (WordCount = 2400)

1152 pixels => 1440 bytes => 480 as Hresolution (WordCount = 1440)

960 pixels => 1200 bytes => 400 as Hresolution( WordCount = 1200)

768 pixels => 960 bytes => 320 as Hresolution (WordCount = 960)

CSI clocks are 300 mhz always. You can have oscilloscope trace of clock at the beginning of the discussion.

screen1.png

screen2.png

screen3.png

screen4.png

screen5.pngscreen6.png

in any case there is no error reported from the configuration tool yet.

Thank you for you help,

Best Regards,

0 Likes

hi srdr,

do you need some other screen copies or is it ok ?

Thank you for your help,

Best Regards

0 Likes

Lebrun,

Firstly, let us focus on 960x540 resolution.

Set Phy delay as 11 instead 5. This is calculated as per the THS_Prepare and THS_Zero provided by you in the tool.

SetPhyDelay API does not validate this parameter. It just sets this value. Hence, it returns Success even you set 5.

Please probe the Clock and Data lines of MIPI Interface and see whether the sensor is providing the THS_Prepare and THS_Zero and data as per configuration.

0 Likes

Hi srdr,

we focus on 960x540.

when modifying the PhyDelay value from 5 to 11, I notice that the displayed error counters change. So I made so further modifications and when I set PhyDelay to 22, there is no more mipi errors displayed with dedicated thread (Get MipiErrors every 5s). That's a big headway.

When examining LV signal, there are "peaks" every 1 ms but this is not what is expected. The state machine is stalled in state 9 or 10 (partial buffer) and there is only one callback from this state. even with a CyU3PDmaMultiChannelSetWrapUp command, it is stuck in this state. That's also the reason I guess for which there is no FV visible on test pin.

Is PhyDelay = 22 an acceptable value ?

thank you for your help,

Best Regards

0 Likes

here is a screen copy of the LV_test output.

tek00002.png

so there is now a signal on it, too short for being a "real valid lv" but repeatable. with PhyDelay = 5, nothing was outputted here.

state machine state is stuck to 9 or 10. After a wrap up + restart state commands, it returns to 9 or 10 at final state.

Best Regards.

0 Likes

Srdr,

here is a screen copy of lv signal with a 1152x720 resolution. the sensor is 10 bits/pixels so there are 1152*10/8 = 1440 valid bytes / line. Bus size is 24 bits wide and pclk is 100 Mhz. So one line is equivalent to => (1440/3 ) = 480 cycles@100Mhz thus : 4.8us. Here we have only one third of this value : 1.6 us. And of course, in fine, we have roughly one third of data frame retrieved. The rythm is not very high in this condition, so CX3 dmacallback mecanism with "manual many_to_one"  should be ok.

We are wondering where does this factor "3" comes from ? Could it be linked to the hResolution parameter of "SetIntf" cx3 api ? Changing this value doesn't display any change of behavior for this particular timing : how is it possible ? what's the final use of this hResolution ?

We are working with RGB888 as input CX3 configuration as before.

If you look closely at picture, you'll see another timing of 565 ns also. This should be the first sent line by sensor that is different and of a fixed size. This fixed size fulfils exactly the timing of this .

Thank you for your help,

Best Regards.

tek00001.png

0 Likes

SetPhyValue 11 is fine. This value is calculated based on THS Prepare and THS Zero provided by you and PCLK (GPIF interface) generated by the MIPI Tool.

i.e Roundof { [THS_Prepare + (THS_Zero/2)] / [(1/ (PCLK*1000)] -1}

Can you please confirm whether you have got THS Prepare and THS Zero from the vendor of Image sensor or you have entered some value?

You can measure this data by probing MIPI lines.

It looks like your data is in RAW 10 format. But the you are providing input data as RAW8 in the MIPI configuration Tool. Can you please check this and modify the input data format in the MIPI Tool then generate the configuration, if needed.

If your data in in RAW 8 format, the LV high should be around 3.87 us for 1152 x 720 resolution. You can check this parameter at bottom right corner of MIPI configuration tool, CX3 Receiver Configuration Tab. You can cross the number of bytes per a line using this number and PCLK.

i.e Roundof (3.87 us * 99.20 Mhz) * 3 bytes =  384 * 3 = 1152 bytes

0 Likes

Hi,

Data are indeed in raw10 format. that's why it is not 384 bytes but 480 from my opinion. but typically the computation stays valid and we should have 4.8us / line. I agree.

I guess the issue is probably from the sensor configuration side now.

Thank you for your help,

Best Regards

0 Likes

Okay.

Please check on Sensor side.

0 Likes

Hi srdr

we have retrieved information from senor manufacturer.

Indeed, with your formula, the estimated delay is not 11 but 6. However this doesn't change much current behavior.

My guess is that LV has still an uncorrect size when cx3 is retrieving data from sensor.

In the setintf function, what is the use of hResolution in procedure ? Changing this parameter doesn't change anything in behavior of CX3 : is this normal ?

Thank you for your help,

Best regards,

0 Likes

hresolution parameter does not have any effect on the MIPI CSI-2 configuraiton. This is normal.

0 Likes

issue was initiated because sensor sent frame + extra data. these extra data size was not a multiple of 3 and that could not be corrected after.

We manage to avoid the send of the extra data and after that, all sent lines have a size multiple of 3 and that's it.

0 Likes

Thank you for the summary!

0 Likes

Hi srdr.

case is now considered solved.

we have a working configuration.

thank you for your help,

Best Regards,

0 Likes