LCD shows wrong colors

sarhangpour · ‎2014-07-20

Posted on July 20, 2014 at 19:52

I'm using a 7'' 800x480 LCD, + SSD1963 driver.

The combination is connected to an STM32F103ZET6, via FSMC.

I have modified a header file to initialize ssd1963, things seem to work as expected, texts and fonts are OK, but there's a problem:

Some colors are shown incorrectly, blue is OK, red is OK, green is something else, black is green, yellow is somehow white.

The worst thing is white, it causes the LCD to hang and mess things up. also, functions like ''GUI_CURSOR_Show()'' cause a hang in LCD as well.

Here's the ssd1963 init routine:

static void _InitController(void) {

U16 driverCode;

LCD_X_Init();

// ------------------------------------

wr_reg(0x00E2, 0x0023);

wr_dat(0x0002);

wr_dat(0x0004);

wr_reg(0x00E0, 0x0001);

delay(1);

wr_reg(0x00E0, 0x0003);

delay(5);

wr_cmd(0x0001);//wr_reg(0x001, 0x0000);

delay(5);

wr_reg(0x00E6, 0x0004);

wr_dat(0x0093);

wr_dat(0x00E0);

wr_reg(0x00B0, 0x0020);

wr_dat(0x0000);

wr_dat((HDP>>8)&0x00FF);

wr_dat(HDP&0x00FF);

wr_dat((VDP>>8)&0x00FF);

wr_dat(VDP&0x00FF);

wr_dat(0x0000);

wr_reg(0x00B4, (HT>>8)&0X00FF);

wr_dat(HT&0X00FF);

wr_dat((HPS>>8)&0X00FF);

wr_dat(HPS&0X00FF);

wr_dat(HPW);

wr_dat((LPS>>8)&0X00FF);

wr_dat(LPS&0X00FF);

wr_dat(0x0000);

wr_reg(0x00B6, (VT>>8)&0X00FF);

wr_dat(VT&0X00FF);

wr_dat((VPS>>8)&0X00FF);

wr_dat(VPS&0X00FF);

wr_dat(VPW);

wr_dat((FPS>>8)&0X00FF);

wr_dat(FPS&0X00FF);

wr_reg(0x00F0, 0x0003);

delay(5);

wr_cmd(0x0021);//wr_reg(0x0021, 0x0000);

wr_reg(0x00BC, 0x0080);

wr_dat(0x0080);

wr_dat(0x0001);

wr_reg(0x00B8, 0x000F);

wr_dat(0x0001);

wr_reg(0x00BA, 0x000F);

delay(5);

wr_cmd(0x0029);//wr_reg(0x0029,0x0000);

// -------------------------------------

}

Any ideas? I guess the wiring is correct because texts and some colors like blue are shown correctly.

Thanks,

Ali

P.S.: I use emWin.

Tesla DeLorean · ‎2014-07-23

Posted on July 23, 2014 at 23:37

Like you have the bit boundaries/mode wrong.

You still writing 48-bits?

wr_dat((rcode << 😎 | (gcode));

wr_dat((bcode << 😎 | (rcode));

wr_dat((gcode << 😎 | (bcode));

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

sarhangpour · ‎2014-07-23

Posted on July 24, 2014 at 07:29

You mean the LCD panel vendor, or the driver board? For the driver board, it's a generic Chinese product without any reference to a manufacturer.

And for the LCD, I'll check that.

No, I used emWin commands:

GUI_DrawGradientV(0, 0, 49, 479, 0x000000, 0x0000FF);

GUI_DrawGradientV(50, 0, 99, 479, 0x000000, 0x00FF00);

GUI_DrawGradientV(100, 0, 149, 479, 0x000000, 0xFF0000);

The codes you mentioned are low level codes I tried to use to bypass the emWin library and see what would happen, at the moment they are not being used.

sarhangpour · ‎2014-07-24

Posted on July 24, 2014 at 14:25

I monitored the output pins of SSD1963 (connection to LCD), when it is going to crash, all signals on these pins disappear. Meanwhile, the STM32 side still sends data with no problem. So I can safely conclude that it is SSD1963 that hangs up.

Another observation is that SSD1963 seems to be very noise prone, if I turn on/off a power supply on my desktop (no connection to my system), produced noise causes ssd1963 to hang.

Tesla DeLorean · ‎2014-07-24

Posted on July 24, 2014 at 15:11

You mean the LCD panel vendor, or the driver board? For the driver board, it's a generic Chinese product without any reference to a manufacturer.

Ok, but where did you source the hardware from, and what part numbers where used to order them, or are printed on the boards?

Make sure you have adequate gauge power/ground connections, and that your power source/regulation is sufficient for the display. Details that might exist in documentation.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

sarhangpour · ‎2014-07-24

Posted on July 24, 2014 at 17:28

About the noise susceptibility, you're right. Everything is wired with not-so-good connections, thanks for the advice, I will take care of that later.

About the main problem, I'm reading some documentation and will try a solution very soon. I'll update this thread with progress reports.

And let me say thank you very much clive1, ever since I started working with STM32, your tips (on this and other threads) have been really helpful. Such a profound knowledge, combined with a helpful personality... You're the best 🙂

sarhangpour · ‎2014-07-24

Posted on July 24, 2014 at 22:38

And... SUCCESS!

Yeah the damn thing is working fine now! We have the white color, even it shows the cursor perfectly well!

I was playing with timings of FSMC (Address SetUp Time, Address Hold Time, Data SetUp Time), and quite by chance, realized that in some combinations, I have a marginal success.

By ''marginal'', I mean I could write a very small word in white, but not a sentence. So I concluded that probably SSD1963 is losing its sync with STM32 in some special cases.

Then I thought about clive1's idea of having a better ground between STM32 and SSD1963 (boy, this guy rocks!), and added another ground path to the connection, and the world became a beautiful place again!

Because the data rate is very high between STM32 and SSD1963, it's absolutely important to have very good and reliable connections between them.

Thank you again clive1!

Tesla DeLorean · ‎2014-07-24

Posted on July 24, 2014 at 23:05

Super, glad you got the issue tamed.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..