1 2 Previous Next 24 Replies Latest reply on Aug 2, 2018 10:38 PM by srdr

    CX3 CSI clock validation

    user_16672

      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.

        • 1. Re: CX3 CSI clock validation
          user_16672

          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,

          • 2. Re: CX3 CSI clock validation
            srdr

            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

             

             

            • 3. Re: CX3 CSI clock validation
              user_16672

              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

              • 4. Re: CX3 CSI clock validation
                srdr

                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.
                • 5. Re: CX3 CSI clock validation
                  srdr

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

                  This resets the MIPI Block.

                  • 6. Re: CX3 CSI clock validation
                    user_16672

                    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,

                    • 7. Re: CX3 CSI clock validation
                      srdr

                      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.

                      • 8. Re: CX3 CSI clock validation
                        user_16672

                        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.

                        • 9. Re: CX3 CSI clock validation
                          user_16672

                          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,

                          • 10. Re: CX3 CSI clock validation
                            user_16672

                            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,

                            • 11. Re: CX3 CSI clock validation
                              user_16672

                              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,

                              • 12. Re: CX3 CSI clock validation
                                user_16672

                                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

                                • 13. Re: CX3 CSI clock validation
                                  srdr

                                  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.

                                   

                                  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.

                                  • 14. Re: CX3 CSI clock validation
                                    user_16672

                                    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,

                                    1 2 Previous Next