LVDS Display Output is sometimes shifted

[hardwareheini]

I have trouble with the LVDS output of my i.MX6. Sometimes one bit of the LVDS Datastream is shifted, which leads to a flickering behaviour on the display side.

I can reproduce this error by stopping and starting the framebuffer:

echo 1 > /sys/class/graphics/fb0/blank
echo 0 > /sys/class/graphics/fb0/blank

If I do this ~15 times the error occurs and stays, until I repeat the commands above. What happens is attached in the two pictures in the attachement. Green and Yellow are my LVDS-Lines. ENABLE, HSYNC, VSYNC and DOTCLK are the output of my de-multiplexer.

1. Normal.png is the normal state. HSYNC and VSYNC happen at the same time.
2. Error.png is the error case. HSYNC and VSYNC don't happen at the same time. VSYNC is shifted from "Falling Edge" to "Rising Edge". There is an additional state on the LVDS Signal (Red Lines.

• i.MX6 DualLite MCIMX6U5EVM10AB
• Resolution: 1200x320
• LVDS Clock 23MHz (x-clock 43.000)
• VSYNC is LOW for 4 lines
• HSYNC is LOW for 10 pixels
• Left Margin: 150 Pixel
• Right Margin: 150 Pixel

I would be happy about any hint where to look for the problem.

kind regards,
Christian

[bhamynarasimhas]

Hi Christian,

We also observe similar issue with IMX6Q and LVDS display. Kindly let me know if you have found the solution?

[hardwareheini]

Hello Bhamy,

bhamynarasimhashenoy‌ tomkuestersteffen‌

I did not find a solution :smileysad:

We were using an i.MX6 with a pre-compiled linux where these errors occured. So there were no way for me to debug this linux whithout having the sources. Also, I'm an FPGA-programmer and not a linux guy.

We then decided to write our own kernel using Yocto Linux. Although we used the same parameters in the new Yocto Kernel as in the old Kernel, the Display-Flicker-Error went away.

Some more information which might help you:

• We were provided with S0-DIMM-Modules incorporating the i.MX6 running Linux. The error was depending on these boards. Some of these modules produced the error, some did not.
• If you changed the error-prone S0-DIMM-Module into another base hardware, the error followed.
• When we sprayed the i.MX6 with cold spray the error went away for a while. We did some research and our i.MX6 was miles below a critical temperature.
• We run the internal PLL out of spec. The lower limit of the video PLL is much higher than the 25MHz we use for the displayclock of our displays. Changing this should be easy, there is an switch in the video settings (I don't know which, sorry). But doubling the frequency of the display would mean a lot of work on the FPGA-Side.

kind regards,

Christian

[tomkuestersteff]

Christian,

We are seeing the same thing on a product using i.MX6Q and an LVDS display - did you ever find an explanation or resolution to this issue?

[igorpadykov]

Hi Christian

one can try to narrow down issue, if this is caused by i.MX

or "de-multiplexer" subsystem (deserializer) by checking with oscilloscope

lvds stream described in sect.6.3 Bit Mapping & Interface Definition

HannStar datasheet, found on

IPU Usage on IMX6 processor.. 

In general deserializer shifting may be caused by lvds signal noise, caused by long

lcd cable, lvds impedance mismatch or overall board noise.

Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[hardwareheini]

Hi Igor,

thank you for your input. I am certain that this behaviour is caused by the i.MX6. I can rule out the LVDS-traces. Why? Because the boot process decides if the error occurs.

1. If the error does not occur, my design runs for hours without any error
2. If the error occurs, then it stays persistent until I a) reboot the Linux on the i.MX6 or b) Restart the device (which reboots Linux as well) or c) issue the commands in my first posting.

This reproducable behaviour is not one I would expect from a mismatched LVDS-Line.

kind regards,

Christian

[igorpadykov]

Hi Christian

one can check with oscilloscope lvds stream if syncs are shifted or not.

This will point source of misbehaviour.

Best regards
igor

[hardwareheini]

Hi Igor,

In the following picture, the No-Error-Case, you can see two traces in the upper half. This is my LVDS-Signal coming from the i.MX. Green is the CLOCK. Yellow is DATA2. In DATA2 are the sync pulses (VS, HS, DE) multiplexed. In the lower half of the picture are the outputs of my LVDS De-Multiplexer. HSYNC and VSYNC are happening at the same time.

On the LVDS there is one state transition:

1. From HSYNC=1;VSYNC=0 (pink Lines) to HSYNC=0;VSYNC=1 (orange traces).

This is reflected in my De-Multiplexer Output.

In the following picture, the Error-Case, the edges of HSYNC and VSYNC are happening at different times. And there are two transitions:

1. From HSYNC=1; VSYNC=0 (pink Lines) to HSYNC=1; VSYNC=1 (red Lines)
2. From HSYNC=1; VSYNC=1 (red Lines) to HSYNC=0; VSYNC=1 (orange Lines)

This is reflected in the De-Multiplexed Output as well and causes my display to flicker.

As a reminder here the Bit-Mapping of the i.MX6

Kind regards,

Christian

[igorpadykov]

Hi Christian

if you think that this is i.MX issue, standrad procedure to submit it as

silicon bug, is that this should be reproduced on Sabre SD board

 

Best regards
igor