Bring up of Ampire 800x480 display on iMX6/WEC7

We are trying to bring up an Ampire display on iMX6S but have some difficulties finding the correct timing parameters (splash screen settings). Please find attached the schematics of our board and the specs of the display.

With the current settings the screen is first dark and the continuously gets brighter until it is completely white:

set ss
ss.fileaddr:	0x0	(FlashAddress with SplashScreen Data)
ss.filesize:	0		(Size of SplashScreen Data)
ss.enable:	1		(Enable SplashScreen)
ss.dbginfo:	0		(Enable DebugInfos)
ss.res:	0x0	(Reserved Flags)
ss.width:	800		(Display Width)
ss.height:	480		(Display Height)
ss.bpp:	32		(BitsPerPixel)
ss.ldds:	24		(LCD Lines Used)
ss.type:	1		(Display Type (0=Passive, 1=Active))
ss.color:	1		(0=Mono, 1=Color)
ss.dual:	0		(0=SinglePanel, 1=DualPanel)
ss.overlay:	0		(Overlay Enable)
ss.dpc:	0		(Double Pixel Clock)
ss.pcp:	0		(Pixel Clock Polarity)
ss.oep:	0		(Output Enable Polarity)
ss.hsp:	0		(Horizontal Sync Polarity)
ss.vsp:	0		(Vertical Sync Polarity)
ss.bs:	5		(LCD Buffer Strength)
ss.pclk:	33260000		(PixelClock (in Hz))
ss.hsw:	41		(Horizontal Sync Width)
ss.vsw:	10		(Vertical Sync Width)
ss.blw:	2		(Begin of Line Width)
ss.elw:	2		(End of Line Width)
ss.bfw:	2		(Begin of Frame Width)
ss.efw:	2		(End of Frame Width)
ss.acb:	0		(AC Bias Frequency)
ss.disp_gpio:	0		(Display On/Off SO-DIMM/MXM3 pin (0 means no pin used for this purpose))
ss.bl_gpio:	0		(BackLight On/Off SO-DIMM/MXM3 pin (0 means no pin used for this purpose))
ss.dispondelay:	0		(Display On Delay)
ss.disp_pol:	1		(Display On/Off polarity)
ss.bl_pol:	1		(BackLight On/Off polarity)
ss.pcddiv:	0		(Enable Pixel Clock PreDivider)
ss.out:	0		(Output device (Apalis: 0=VGA,1=parallel,2/3/4=LVDS,5=HDMI Colibri: 0=parallel,5=HDMI))
ss.mode:	0		(Standard mode id (overrides settings))
ss.detectmode:	0		(0=use parms, 1=match EDID info with standard mode, 2=use EDID preferred mode)
ss.noOE:	0		(Disables OE/DE signal)
ss.noVSYNC:	0		(Disables VSYNC signal)
ss.noHSYNC:	0		(Disables HSYNC signal)
ss.jeida:	0		(Enables JEIDA mapping for LVDS)
ss.res:	0x0	(Reserved Flags)
ss.edidaddr:	0x50	(7-bit i2c address, where the EDID EEPROM is located)
ss.edidenable:	0		(1=enable reading of EDID data from i2c EEPROM. 0=disable this feature)

Do you see settings which need to be corrected?

looks like your display connected incorrectly. It has a 18 bits RGB interface, so please check Table 5-8 Standard Parallel RGB LCD Interface Pins of https://docs.toradex.com/102075-colibri-imx6-datasheet.pdf

You are right, just the higher significant bit lines of the RGB signal are connected. That’s why I configured ss.ldds=24. Shouldn’t that work in principle? (see also slide 27 in https://www.nxp.com/wcm_documents/techzones/microcontrollers-techzone/Presentations/graphics.lcd.technologies.pdf).

Dear @widtmann

Your wiring seem to be correct at a first glance. I can’t give you a final solution, but I think the following information should help you to narrow down the problem sufficiently to find the root cause:

Let’s first exclude the working signals:

  • The display gets white. This means the whole backlight (LED) circuits are working fine. They are fully independent from the rest of the display, so we can take for granted all these signals are fine.

Then there are some signals which don’t lead to the described problems:

  • Even if the color signals are wired completely wrong, it would never lead to a fade-out effect. You would see wrong colors or maybe some noise. Therefore we can ignore the signals R0…7, G0…7 and B0…7.

So there’s only a few signals left that you need to look at:

  • PCLK
  • DEN
  • VLCD2

Your display does not have inputs for VSYNC and HSYNC, but instead works on DEN only for synchronization. In the past we observed several times, that such displays are more sensitive to wrong timings, or a wrong power-up sequence.
The fade-out is a typical indication that any of these timings are not correct.

Timings

[Now as I’m checking the timings, I found the problem here. Rather than deleting the text above, I keep it there, maybe it helps anyway…]

  • Your horizontal blanking times are too short. According to the datasheet your DE period must be 1000-1200 pclk cycles.
    The DE period is ss.blw + ss.width + ss.elw
    → Increase ss.blw and ss.elw to 128 each.
  • Your vertical blanking times are too short. According to the datasheet your DE frame blanking must be 10-110 Lines
    The vertical blanking is ss.bfw + ss.efw
    → Increase ss.bfw and ss.efw to 22 each.
  • You might also need to change ss.oep to 1

Regards, Andy

Thank you for the timing parameters. However, after setting them the display behaved still in the same way. I continued playing around with the parameters and focused on the ones you mentioned above. By chance, I reduced the clock frequency to half of the speed and surprisingly the display works fine now.
Here is the new configuration:

set ss
ss.fileaddr:	0x0	(FlashAddress with SplashScreen Data)
ss.filesize:	0		(Size of SplashScreen Data)
ss.enable:	1		(Enable SplashScreen)
ss.dbginfo:	0		(Enable DebugInfos)
ss.res:	0x0	(Reserved Flags)
ss.width:	800		(Display Width)
ss.height:	480		(Display Height)
ss.bpp:	32		(BitsPerPixel)
ss.ldds:	24		(LCD Lines Used)
ss.type:	1		(Display Type (0=Passive, 1=Active))
ss.color:	1		(0=Mono, 1=Color)
ss.dual:	0		(0=SinglePanel, 1=DualPanel)
ss.overlay:	0		(Overlay Enable)
ss.dpc:	0		(Double Pixel Clock)
ss.pcp:	1		(Pixel Clock Polarity)
ss.oep:	0		(Output Enable Polarity)
ss.hsp:	0		(Horizontal Sync Polarity)
ss.vsp:	0		(Vertical Sync Polarity)
ss.bs:	5		(LCD Buffer Strength)
ss.pclk:	16630000		(PixelClock (in Hz))
ss.hsw:	41		(Horizontal Sync Width)
ss.vsw:	10		(Vertical Sync Width)
ss.blw:	128		(Begin of Line Width)
ss.elw:	128		(End of Line Width)
ss.bfw:	22		(Begin of Frame Width)
ss.efw:	22		(End of Frame Width)
ss.acb:	0		(AC Bias Frequency)
ss.disp_gpio:	0		(Display On/Off SO-DIMM/MXM3 pin (0 means no pin used for this purpose))
ss.bl_gpio:	0		(BackLight On/Off SO-DIMM/MXM3 pin (0 means no pin used for this purpose))
ss.dispondelay:	0		(Display On Delay)
ss.disp_pol:	1		(Display On/Off polarity)
ss.bl_pol:	1		(BackLight On/Off polarity)
ss.pcddiv:	0		(Enable Pixel Clock PreDivider)
ss.out:	0		(Output device (Apalis: 0=VGA,1=parallel,2/3/4=LVDS,5=HDMI Colibri: 0=parallel,5=HDMI))
ss.mode:	0		(Standard mode id (overrides settings))
ss.detectmode:	0		(0=use parms, 1=match EDID info with standard mode, 2=use EDID preferred mode)
ss.noOE:	0		(Disables OE/DE signal)
ss.noVSYNC:	0		(Disables VSYNC signal)
ss.noHSYNC:	0		(Disables HSYNC signal)
ss.jeida:	0		(Enables JEIDA mapping for LVDS)
ss.res:	0x0	(Reserved Flags)
ss.edidaddr:	0x50	(7-bit i2c address, where the EDID EEPROM is located)
ss.edidenable:	0		(1=enable reading of EDID data from i2c EEPROM. 0=disable this feature)

Do you have an explanation why it is working like this?

Dear @widtmann

Can you measure the actual pixel clock frequency?

The pixel clock is derived from other clocks, and only particular frequencies can be achieved. Maybe your initial frequency of 33.26MHz was rounded up to a value which the display could not handle anymore.

Usually displays can handle a rather wide range of pixel clock frequencies. By cutting the pixel clock in half, you end up with a frame rate of around 30Hz, which is rather low. I recommend to use some pixel clocks between 16 and 33MHz to find a better compromise.

Regards, Andy

I tried different clock settings and found that the display works between 6 and 25 MHz. I’ll go with 17 MHz in this case.
Thank you for your support!

We finally figured out the main problem in our hardware. Due to a mistake in the circuit the amplitude of the clock signal was too low. After fixing the hardware the display works well at clock frequency of 33.26MHz.

Dear @widtmann

Thank you for the feedback. I’m glad to hear that you found the root cause of the issue. This always gives much more confidence in the stability of a system, compared to just finding a workaround which works “magically”.

Regards, Andy