AM3352 18bit RGB LCD

Can you post a picture of what it looks like?

Please see this video. The flickering occurs when there is a change in text.

The lines printing the same character doesnt have any issues. The flickering occurs in the line with print "ABCDEFGH.."

Is this a parallel display? What is the cable length? Do you have any serial resistors on the LCD lines?

1. 18bit parallel RGB display

2. Cable length = 60cm

3. We have serial resistors and beads on these lines. (http://e2e.ti.com/support/arm/sitara_arm/f/791/p/342326/1196807.aspx#1196807)

60cm is way too long for a parallel display. Check your signals at the display end of the cable. I suspect you have signal integrity issues.

We are using the same cable with the customer board and found no issues.

I'm afraid I don't understand. On what board do you see this issue? And what software are you using? Linux normally uses a Ping-Pong frame buffer, application writing in the half of the buffer that isn't currently being displayed.

I got the issue on the custom board of AM3352 with linux OS 3.12. What is this ping pong buffer???

See this wiki http://processors.wiki.ti.com/index.php/Linux_Core_LCD_Controller_User_Guide

Unfortunately i have no idea about this. Let me discuss with team. :)

Any idea how this flickering occurs only for RGB = FFFFFF and that too in some areas of the LCD ?

Afraid I don't have any other ideas, without knowing how do you write to the screen.

How do you write means????

I mean what Linux version you use, how is your LCD driver configured, what procedure you use to write to the LCD. It could be a hardware problem, it could be software. I don't have enough information to offer any advice or ask for support.

1. We have used the linux version along with SDK 7.0 (linux 3.12) .

2. LCD driver configured for 18bit RGB LCD (24bpp mode) for 640x480 resolution.

lcdc: lcdc@0x4830e000 {
pinctrl-names = "default", "sleep";
pinctrl-0 = <&lcd_pins_default>;
status = "okay";
display-timings {
640x480 {
hactive = <640>;
vactive = <480>;
hback-porch = <116>;
hfront-porch = <44>;
hsync-len = <16>;
vback-porch = <34>;
vfront-porch = <11>;
vsync-len = <3>;
clock-frequency = <25000000>;
hsync-active = <0>;
vsync-active = <0>;
de-active = <1>;
pixelclk-active = <0>;
};
};
};

We have both RGB and LVDS display in our custom board , one display active at a time. LVDS display is working properly. Issue found in RGB only.

Our implementation is shown below. We have used 33 ohm resistor pack for display type selection. 

If you are using the same software and LCD configuration in both cases, this definitely points to a PCB signal integrity issue with the parallel display. For example, if you have long stubs (from the LVDS junction) on the traces, these are likely to cause signal distortion.

If so, why the LVDS display is not getting affected?

I cannot say, having no idea what PCB looks like.

yes.. i know...:)

The RGB signals go through 33 ohm resistors then ferrite beads near the connector. Let me short the resistors and check the behaviour. 

No improvements found. Now i doubt the ferrite beads in the line. Let me short them and check. Do you have any views on this. I found some improvements in touchscreen while shorting beads.