Custom MIPI image sensor to iMX6

[ndsonu]

Hello,

We have a custom board based on i.MX6 (Quadcore). Four analog video inputs need to be fed to the imx6.

As shown in the below diagram, using a Conexant chip we multiplex and convert analog video into a single BT656  Digital out.This digital data is converted to MIPI by a  lattice semi based FPGA.

Unfortunately we are not receiving the video.

Following registers in the iMX6 MIPI Host controller are checked.

MIPI_CSI_PHY_STATE  gives  both  0x300  and  0x630 ,  but 0x300 is frequent.

Both error registers , MIPI_CSI_ERR1 and  MIPI_CSI_ERR2 gives a value of 0x00.

Do the above register values say that my MIPI receiving section is receiving data correctly?

Is there anything that we can look in from any other registers?

Thanks in advance.

Thanks,

sonu

[igorpadykov]

Hi Sonu

it may be suggested to look at debug steps

Some Experience When Enable MIPI Camera

Best regards

igor

[ndsonu]

Hi Igor,

Thank you for your response.

We looked into the link you mentioned.

Unfortunately we couldn't get our interface working.

Could you please go through the below notes

Our System Setting :

++++++++++++++++++++

The set up contains 2 parallel cameras and one MIPI interface.We are using a custom video pipeline driver

Parallel  cameras are connected to the iMx6 IPU0-CSIO and IPU1-CSI1 resepectively and this is working fine.

The MIPI imgae source is interfaced to IPU0-CSI1.

FPGA ( our MIPI image source)  is programmed to send the MIPI video in Virtual Channel - 1.

Also the MIPI- DPHY is emulated in the FPGA with the help resistors.

(we are using reference design from Lattice Semi : http://www.latticesemi.com/~/media/Documents/ReferenceDesigns/NR/ParalleltoMIPIDSITXBridge.pdf?docum...)

Device Tree Configuration:

++++++++++++++++++++++++++++++++++++

mipi_csi: mipi_csi@021dc000 {

  compatible = "fsl,imx6q-mipi-csi2";

                ipu_id = <0>;

                csi_id = <1>;

                v_channel =<1>;

                lanes =<2>;

  reg = <0x021dc000 0x4000>;

  interrupts = <0 100 0x04>, <0 101 0x04>;

  clocks = <&clks 138>, <&clks 53>, <&clks 204>;

  /* Note: clks 138 is hsi_tx, however, the dphy_c

  * hsi_tx and pll_refclk use the same clk gate.

  * In current clk driver, open/close clk gate do

  * use hsi_tx for a temporary debug purpose.

  */

  clock-names = "dphy_clk", "pixel_clk", "cfg_clk";

  status = "okay";

  };

Board File Configuration : ( for parallel cameras)

++++++++++++++++++++++++++

regmap_update_bits(gpr, IOMUXC_GPR1, 1 << 19, 1 << 19);

regmap_update_bits(gpr, IOMUXC_GPR1, 1 << 20, 1 << 20);

MIPI-CSI Host Side Configuration :

+++++++++++++++++++++++++++++++++++++

mipi_csi2_info:

   mipi_csi2_info.mipi_en   = 1

   mipi_csi2_info.ipu_id    = 0

   mipi_csi2_info.csi_id    = 1

   mipi_csi2_info.v_channel = 1

   mipi_csi2_info.lanes     = 1

   mipi_csi2_info.datatype  = 0x1e (YUV422)

Observations :

+++++++++++++++

Start up and execution  :

            Will keep the MIPI lanes ( CK,D0 and D1) in LP-11 state from FPGA .

            The MIPI-HOST controller section of i.MX6 is configured as mentioned in the i.MX6 resource manual chapter 40.         

            The MIPI_CSI2_DPHY_STATUS at this stage is 0x630.

            Start the FPGA pump data out.

            The FPGA clock and data lanes start to switch between LP and HS modes.

            We see activity on all the lanes in oscilloscope ( CK+,CK-, D0+,D0-,D1+,D1-)

            The MIPI_CSI2_DPHY_STATUS at this stage switches between 0x300 and 0x630.But we are not receiving any IPU interrupts.

            Also the following registers are monitored.

               mipi_csi2_dphy_status = 0x300

               mipi_csi2 error1 = 0x2000000

               mipi_csi2 error2 = 0x0

               MIPI_CSI2_DATA_IDS_1 = 0x0

               MIPI_CSI2_DATA_IDS_2 = 0x0

               MIPI_CSI2_N_LANES = 0x1

Otherwise we are get everything similar to what is mentioned in the document  "Debug steps for customer MIPI sensor.docx"

From this we understand that there is a checksum error in Virtual Channel -1 in the received data.

As an experiment we changed the virtual channel to 0 in FPGA.

Then in the iMX6 side the error shifted , mipi_csi2 error1 = 0x1000000. From this can we conclude that Data ID was correctly deteced by MIPI Host controller.

Is there any way to dump the received data to memory ( though there is error)  from where we can manually compare it with the transmitted data and see what is happening?

Any help to debug our issue is highly appreciated.

Thanks,

Sonu

[OmarPighi]

Hi Sonu,

I'm reading your post very late. I hope you already solved your issue.

I have a similar configuration but with the difference that for me the video come from an Aptina monochrome CMOS sensor. I also used Lattice MachXO2 to convert flow from parallel to MIPI (2 Lane). I take two months to solve all my problems. During my tests I also had your (and a lot of others!) problem on mipi_csi2 error1. In my case the problem was that my sensor has a particular timing on FV and HV signals. In particular the rising edge of HV is very close to rising edge of FV (6 pixels) and mipi serializer doesn't have time to produce the short packet for the "frame start". For a similar situation also the short packet at the and of the frame ("frame end") was missing. I solved the problem setting the sensor to produce one more line at the beginning of the frame before the first active line.

I don't know if it's could be the same problem for you. Anyway I suggest to you to verify with the scope the presence of the "Frame Start" and "Frame Stop" short packet. I don't have a MIPI analyzer so it was very difficult to read the content of the packet but with the use of math functions it's not impossible.

Bye Bye.

[ndsonu]

Hi Omar.

Thanks a lot for your reply.

Yes, we solved our problem.

In our  case , the problems were mainly in the Lattice reference code we were using. It was inserting wrong "ECC" in the MIPI packets. Also the Wordcount interserted by the code was wrong. With this corrected all our errors were gone and we were able to get the MIPI packets in memory.

Cheers,

Sonu

[jwatts]

Huge apologies for posting to a 2-year-old thread, but our use case is just about precisely the same as yours and we're having trouble with one last facet of capture: We are successfully capturing frames, but the IMX seems to be ignoring SOF and EOF packets. If there is any hiccup in reception, or if the IMX takes too long to begin receiving MIPI data, then it begins part-way through the "first" frame and delivers an un-synchronized stream. Some times we get continuous NFB4EOF errors, and sometimes we don't, but the frame offset remains constant until we stop and restart the entire capture chain. Did you ever encounter this kind of issue?

Here's an example of our capture:

[tamilarasane]

Hi,

I am trying to interface the single lane MIPI sensor OV7251 sensor with imx6. MIPI_CSI_PHY_STATE register value is continuously changing between 0x0000_0300 and  0x0000_0310.   MIPI_CSI_ERR1 and MIPI_CSI_ERR2 status registers are also zero. But Frames are not coming to memory.

Q1

Is the above status registers denotes iMX6 receiving MIPI packets or not?

Q2

How should I know weather iMX6 received  MIPI packets or not

Q3

we have configured single lane in dts file. Is there other things need to configure  at imx6 side for single lane?

Q4. 

 anybody interfaced  0V7251 single lane MIPI with imx6?

Thanks 

Tamilarasan

[OmarPighi]

Great!!

One question: what about continuous or non-continuous clock?

I was not able to work with non-continuous clock so i worked with continuous clock. But I needed to do some changes in startup sequence. I introduced a Low Power sequence (LP11 -> LP10 -> LP00) for the clock before to start data stream. Without this sequence the IMX6 MIPI_CSI_PHY_STATE gives errors. Unfotunately the Lattice reference I used didn't provide this sequence. In continuous mode FPGA starts to move clock without any Low Power sequence at the beginning of transmission.

Did you encounter the same problem?

Many thanks.

[ndsonu]

Hello Omar,

We are working with non-continuous clock.

We  edited the FPGA code to introduce the Low power sequence as you have mentioned to get the MIPI register configurations correct.

Thanks,

Sonu