LCD colors look wrong. Android 4.3 with18-bit Parallel RGB on IMX6S.

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

LCD colors look wrong. Android 4.3 with18-bit Parallel RGB on IMX6S.

Jump to solution
7,607 Views
mukelarvin
Contributor IV

Photo 2014-07-14, 3 58 19 PM.jpg

I'm trying to get a HX8369A based lcd to display 18-bit parallel RGB. I've got it working but the colors look terrible. A lot of pixels just go to green like the color data is incorrect. I've tried a variety of timings but it doesn't help.


Does this seem like a timing issue? Is the software giving bad color data? Could my LCD be expecting color data in a slightly different format?

I'm using an IMX6S based RIoTboard which only has DISP_DAT0 - DISP0_DAT17 accessible on the header so I can't use 24 bits. Kernel 3.0.35, Android 4.3.

Boot Arguments:

setenv bootargs console=ttymxc1,115200 init=/init video=mxcfb0:dev=lcd,CLAA-WVGA@60,bpp=18,if=RGB666 video=mxcfb1:off fbmem=10M vmalloc=400M androidboot.console=ttymxc1 androidboot.hardware=freescale

Timing in mxc_lcdif.c:

static struct fb_videomode lcdif_modedb[] = {

  {

     "CLAA-WVGA", 60, 480, 800, KHZ2PICOS(25000), 5, 5, 2, 2, 5, 2,

     FB_SYNC_CLK_LAT_FALL,

     FB_VMODE_NONINTERLACED,

     0,

  },

//...

}

FB configuration in board-mx6solo_RIoTboard.c:

static struct fsl_mxc_lcd_platform_data lcdif_data = {

  .ipu_id = 0,

  .disp_id = 0,

  .default_ifmt = IPU_PIX_FMT_RGB666,

};

//...

static struct ipuv3_fb_platform_data RIoTboard_fb_data[] = {

  {

  .disp_dev = "lcd",

  .interface_pix_fmt = IPU_PIX_FMT_RGB666,

  .mode_str = "CLAA-WVGA",

  .default_bpp = 18,

  .int_clk = false,

  },

//...

}

Pin Muxing in board-mx6solo_RIoTboard.h:

/* DISPLAY */

  MX6DL_PAD_DI0_DISP_CLK__IPU1_DI0_DISP_CLK,

  MX6DL_PAD_DI0_PIN15__IPU1_DI0_PIN15, /* DE */

  MX6DL_PAD_DI0_PIN2__IPU1_DI0_PIN2, /* HSync */

  MX6DL_PAD_DI0_PIN3__IPU1_DI0_PIN3, /* VSync */

  //MX6DL_PAD_DI0_PIN4__IPU1_DI0_PIN4, /* Contrast not connected*/

  MX6DL_PAD_DISP0_DAT0__IPU1_DISP0_DAT_0,

  MX6DL_PAD_DISP0_DAT1__IPU1_DISP0_DAT_1,

  MX6DL_PAD_DISP0_DAT2__IPU1_DISP0_DAT_2,

  MX6DL_PAD_DISP0_DAT3__IPU1_DISP0_DAT_3,

  MX6DL_PAD_DISP0_DAT4__IPU1_DISP0_DAT_4,

  MX6DL_PAD_DISP0_DAT5__IPU1_DISP0_DAT_5,

  MX6DL_PAD_DISP0_DAT6__IPU1_DISP0_DAT_6,

  MX6DL_PAD_DISP0_DAT7__IPU1_DISP0_DAT_7,

  MX6DL_PAD_DISP0_DAT8__IPU1_DISP0_DAT_8,

  MX6DL_PAD_DISP0_DAT9__IPU1_DISP0_DAT_9,

  MX6DL_PAD_DISP0_DAT10__IPU1_DISP0_DAT_10,

  MX6DL_PAD_DISP0_DAT11__IPU1_DISP0_DAT_11,

  MX6DL_PAD_DISP0_DAT12__IPU1_DISP0_DAT_12,

  MX6DL_PAD_DISP0_DAT13__IPU1_DISP0_DAT_13,

  MX6DL_PAD_DISP0_DAT14__IPU1_DISP0_DAT_14,

  MX6DL_PAD_DISP0_DAT15__IPU1_DISP0_DAT_15,

  MX6DL_PAD_DISP0_DAT16__IPU1_DISP0_DAT_16,

  MX6DL_PAD_DISP0_DAT17__IPU1_DISP0_DAT_17,

Does 18-bit color just look this bad?

Labels (3)
0 Kudos
1 Solution
2,917 Views
mukelarvin
Contributor IV

I think I've nearly got it!

SteveRathjen was correct about adding a 330 Ohm resistor inline with the CLK signal. That improved the image dramatically.

Photo 2014-07-28, 2 31 57 PM.jpg

Then using the patches louiskoziarz recommended as a guide I changed the CLK pin strength, I bumped the control type up to PAD_CTL_DSE_240ohm and have a nearly perfect image. Although there are still a few errant blue pixels.

Photo 2014-07-29, 9 47 05 AM.jpg

I have asked my coworker to add pads for inline resistors on all the display lines for the next version of our board. I'm sure that tuning those values and the pin strengths will help us get a perfect image.

Thanks to everyone for their help!

View solution in original post

0 Kudos
21 Replies
2,918 Views
mukelarvin
Contributor IV

I think I've nearly got it!

SteveRathjen was correct about adding a 330 Ohm resistor inline with the CLK signal. That improved the image dramatically.

Photo 2014-07-28, 2 31 57 PM.jpg

Then using the patches louiskoziarz recommended as a guide I changed the CLK pin strength, I bumped the control type up to PAD_CTL_DSE_240ohm and have a nearly perfect image. Although there are still a few errant blue pixels.

Photo 2014-07-29, 9 47 05 AM.jpg

I have asked my coworker to add pads for inline resistors on all the display lines for the next version of our board. I'm sure that tuning those values and the pin strengths will help us get a perfect image.

Thanks to everyone for their help!

0 Kudos
2,815 Views
dangnq
Contributor I

Hi Luke Marvin,

I have a similar problem on OMAP3. I've found the cause due to clock select of LCD is falling edge but clock of AP is rising edge. I think your's problem too.

0 Kudos
2,825 Views
vikaspatil
Senior Contributor I

Hi Marvin,

Could you please help me here? What all things I need to verify to get LCD working?

Innolux LCD brignup on i.MX6 Solo Sabre based board

Thanks & Regards,

Vikash

0 Kudos
2,825 Views
louiskoziarz
Contributor II

Luke,

I was having a VERY similar problem with an RGB666 LCD and an iMX6Solo.  This was using a Nitrogen6X SOM from Boundary and their 800x480 LCD.


Eric Nelson from Boundary was extremely helpful and tackled the issue.  He's committed two patches to fix the problem for me and it works GREAT.  You might want to give these a try, if not directly pulling them into your kernel then at least you can get the spirit of what is changing here.

Patch 1 corrects the drive strength on the LCD lines.  Eric notes this is normally done in the bootloader but makes sure they're set again in the kernel:

mx6dl_pins: fix drive strength for DISP0_DATA02, DATA10 · eb0beb6 · boundarydevices/u-boot-imx6 · Gi...

nitrogen6x/SABRE Lite: explicitly set the drive strength on LCD interfac... · de33f0b · boundarydevi...

Patch 2 corrects the LCD pixel clock polarity.  According to Eric it was being reset during mode changes.

ipu_disp: preserve display clock polarity · a885ae0 · boundarydevices/linux-imx6 · GitHub

I'm sure Eric would show up here soon and give the same info, I'm paying back the favor by saving him the keystrokes...

2,825 Views
mukelarvin
Contributor IV

Okay I've made those changes to my uboot, kernel and lcd driver. Alas it does not seem to have solved my problem. Certain colours still won't display correctly.

But at least I won't have to worry about that problem later! :smileylaugh:

0 Kudos
2,825 Views
SteveRathjen
Contributor III

Do you have series resistors in line with the LCD signals?  Especially the clock?  I had 33 ohm on all and had similar noise on display.  I found a 330 ohm on the clock line fixed it.

Also make sure your boot cmd has something like "video=mxcfb0:dev=lcd,SEIKO-WVGA,if=RGB666" for 18 bit.

Steve

0 Kudos
2,824 Views
mukelarvin
Contributor IV

My board (Embest Tech RIoTboard) doesn't have any inline resistors on any of the lines.

I took a look at the schematic for the Sabre Lite. It doesn't have any resistors on the data lines but the schematic shows a mystery resistor on the CLK line. Is it just a 0 Ohms resistor? Should I have a resistor on my clock line?

sabreliteLCD.JPG.jpg

0 Kudos
2,824 Views
SteveRathjen
Contributor III

Screenshot from 2014-07-27 10_52_34.png

The SabreSD has these 33 ohm resistors.  I included them on my custom board, but changed CLK resistor to 330 ohm - the noise on the display looked VERY similar to what you see with 33 ohm on the CLK.  I'm using a display with a HX8264 and 24bit.  The noise when connecting the LCD to the SabreSD was 10x compared to my custom board, but I had several "adapters" to get the LCD connected to the SabreSD.

I'd seriously consider trying a resistor 33-330ohm on the CLK line if it's not too much hassle.

Hope that helps!

Steve

2,824 Views
EricNelson
Senior Contributor II

Hey Luke,

The 0-ohm resistor is there to provide an easy spot to hook up a test lead. No more/no less.

0 Kudos
2,824 Views
varsmolta
Contributor V

what LCD is it and what are your init sequences? can you post it here?

0 Kudos
2,824 Views
mukelarvin
Contributor IV

It's a new LCD from Microtips. It uses the HX8369A controller IC. This is the initialization code I was given. I'm bit banging the SPI over GPIOS.

HX8369A_RGB_18bit_Initial - Pastebin.com

0 Kudos
2,824 Views
jalbers
Contributor I

Luke,

Did you ever figure this out? I have a display exhibiting similar issues and I'm curious what worked for you.

0 Kudos
2,824 Views
mukelarvin
Contributor IV

Not yet. I'm compiling a linux build right now to see if the problem still occurs. Does your LCD also use the HX8369A controller IC?

0 Kudos
2,823 Views
jalbers
Contributor I

Nope. My display has 5x HX8232 and 1x HX8655 driver ICs.

I also plan to custom build a kernel and tweak the display settings. I'll let you know what I learn.

0 Kudos
2,825 Views
varsmolta
Contributor V

I believe these are the mappings:

DISP0_DAT0:DISP0_DAT5 - B0-B5

DISP0_DAT6:DISP0_DAT11 - G0-G5

DISP0_DAT12:DISP0_DAT17 - R0-R5

Is this what you have?

0 Kudos
2,825 Views
mukelarvin
Contributor IV

Yes that's how I have them wired up.

I saw another post where some said that in the boot arguments should have bpp = 32 instead of bpp = 18. I changed that and it helped most of the image but there are still certain colors it refuses to display properly.

When I display the following image...

2012-08-11-hsl-spectrum.png

...certain colors just appear as green.

Photo 2014-07-18, 3 57 17 PM.jpg

That leads me to believe it's some sort of encoding problem, rather than a timing problem.

0 Kudos
2,825 Views
varsmolta
Contributor V

Have you tried the LCD on a non-android image? Like yocto linux?

0 Kudos
2,825 Views
mukelarvin
Contributor IV

I have a linux image provided by the vendor however I don't know what the pin muxing is. Is there a way to set the muxing from user space?

The vendor hasn't supplied the source code and I've only been setting pin muxes with define statements. Also this kernel pre-dates device trees.

0 Kudos
2,825 Views
varsmolta
Contributor V

Most likely the pins should be setup for LCDs. One way to confirm them is to use the devregs utility and read the mux settings from user space.

http://boundarydevices.com/i-mx5x-device-register-access/

Note: link is for imx5 but see github link in there for imx6 code.

0 Kudos
2,825 Views
mukelarvin
Contributor IV

Well it turns out the vendor has put up linux source since I last checked. I built an image configured for my LCD but found that I still have the same colour issues. This distribution is using the same kernel and drivers as the Android image did.

So I can at least rule out the OS as the source of the problem. It's either in the kernel video drivers, the hardware lines or the LCD initialization settings.

Photo 2014-07-24, 10 44 35 AM.jpgPhoto 2014-07-24, 10 42 11 AM.jpg

0 Kudos