IPU v3 CSI0, HSYNC and DATA_EN questions in gated clock mode.

[JimMalone]

Hi All,

We are struggling with a 16 bit parallel camera interface hooked up to CSI0 on an i.mx6Solo.

We have the data lines hooked up to CSI0_DAT[19:4] with the MSB hooked to 19.  We are providing PIXCLK, VSYNC and HSYNC.

First question:

HSYNC is shown as being used as a line valid type signal in the Datasheet (Section 4.11.10.2.2 Rev D of the consumer datasheet - similar section for i.mx53).  So it is active high when data is valid per line.  In the Reference manual, (Section 37.4.3.6.1, Rev B of the i.mx6 Solo/DL Reference manual), it shows HSYNC as a single active high pulse with a width of a single pixclk cycle.  We are assuming that the CSI engine is only looking for the rising edge but would like clarification if anyone knows.  I have also checked the i.mx53 documentation and it has the same discrepancy.

Second question:

Is the CSI0_DATA_EN used at all in this interface when in parallel mode?  I can not find much information on the use of this pin at all in the i.mx6 documentation or the i.mx53 documentation.  This signal is used in the MIPI CSI2 mode and routed through the CSI2IPU gasket.  I know this gasket is not used in the parallel mode, but it is the only reference (as well as a timing diagram for data_en) in the entire reference manual.  The reason I ask is we were not driving it (our camera data is passed through an FPGA which drives the CSI0 port) and the FPGA had the pin tristated.  We assumed that a week pullup was pulling this signal high the entire time.  In this mode we are clocking data in, but see blanking data in the active areas when looking at the memory buffers output from the IDMAC.  We then tied the data_en high for the entire operation and saw no change in what we were reading.  Same result on the output.  We tied it low and saw no video sampled at all.  Our FPGA guy then put some logic in to make it work like the gasket layer where the VSYNC fires, Data_en fires, then HSYNC fires, with data_en and HSYNC repeating for each line.  Data_en was off during blanking.  The result was no video sampled.  So needless to say we are all confused by this last result.

I have asked my local FAEs but one is out on travel right now.

Any help would be greatly appreciated.

Thanks,

Jim

[imxcommunitysco · Accepted solution]

Hi Jim,

question 1:

indeed the HSYNC event in capture side is edge triggered, but usually we set it more than one pclk cycles, and this is set in camera sensor side. IPU need to get something prepared when it receives HSYNC and so we should make sure the sync + blanking  period should be long enough(typically no less than %5 of a line period)

question 2:

As I know DATA_EN is not used in parallel sensor in, as I remember it is connected to sensb_data_en inside the chip which is obselete now. Besides, I need to know the capture mode you are using, gated mode or non-gated mode? in gated mode, HSYNC is actually indicating the valid data(same as data enable). and in non-gated mode, pclk is only presented in valid data period.

Thanks,

Ray

[zhuyang]

Hi guys,

          I am facing the similar problem now. I use imx6-sabresd board, and I use a 8 bit parallel sensor. I configured CSI->MEM, Gate Clock mode. Now I can dump sensor data to file using my own test tool. From the dump data, I found imx6 received all the data including active and blanking data just like below

line0:   horizontal blanking data(94 bytes 0)    active data(right format and width)

line1:   horizontal blanking data(94 bytes 0)    active data(right format and width)

......

The blanking data is what i don't want.

I have tried to configure

CSI_SENS_FRM_SIZE

CSI_ACT_FRM_SIZE

CSI_OUT_FRM_CTRL to try to skip the column blanking data, but it still behavior like that.

I also found that if I configure CSI_SENS_CONF bit31 CSI0_DATA_EN_POL to inverse csi0_data_en, i cannot got any sensor data. It seems like the data_en is still effective in imx6, it's not totally obselete? Almost all the freescale documents refering to the CSI timing don't describe DATA_EN at all.

BTW, i have check all the signal wave, there should be no problem. The Vsync is active during whole frame, Hsync is active during whole line except the blanking data, i dont connect any sensor signal to DATA_EN at all. It seems like the VYSNC signal is always valid, and csi sample the data all the time

Question1:

What's the difference between sensor frame size defined in CSI_SENS_FRM_SIZE and actual frame size in CSI_ACT_FRM_SIZE?

Question2:

I know the VSYNC trigger the start sample process of the line but he CSI how to stop sample line data? by calculate line size already received or by other signals?

How anybody could help point out how to remove the horizontal blanking data? Thanks a lot!

[JimMalone]

Hi Ray,

Thanks for the response.  I thought I had it in there but appear to have left out that we are using the gated-mode of clocking video data into the CSI port.

Jim

[paul_lee]

Hi,

imxcommunityscout

I am using 16bit parallel interface to capture a data on CSI port.

We are getting horizontal data correctly, but  we are not able to capture a frame from start of frame.

We are missing some of the vetical lines.

Can you guide me for this issue.

Thanks,

Paul

[aaronblanchard]

Hi Paul,

We also have a similar problem capturing data on the CSI port.  We've set CSI0 up for syncing on the External Vsync but our frame capture starts at random periods throughout the frame.

Did you ever resolve your problem?

Best regards,
Aaron

[aaronblanchard]

We did resolve our problem.

We had a HDMI formatted input going to CSI0 which also used the Data Enable (DE) pin.

No matter what we tried we could not get it to synchronise vertically correctly.

After much playing around, we found that it was the DE which was causing the problem, so we ignored it.  After setting the DE pin to a GPIO output (And hence letting the DE internally go high via weak pullup) we managed to sync.

We of course had to modify the crop boundaries etc. as we had more Hsync information than we previously had.

I hope this helps somebody else.