LCD shows wrong colors

[sarhangpour]

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(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]

Posted on July 20, 2014 at 20:47

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

Why would you need to guess, find a register and memory and read-back the data you have written. If that is right, then you'll need to verify the mode the controller/panel is in, and evaluate what colour data you are writing, and the colour space being used.

[sarhangpour]

Posted on July 20, 2014 at 21:12

Thanks clive1,

I hope that I have done the right thing: I read back ''pixel_data_interface'' register of SSD1963, it was 0x03, which is correct (16-bit (565 format)).

I noticed that if I somehow shake the wires that connect STM32 to SSD1963, LCD freezes as well (it gets messy then freezes). Is there a chance of loose connection?

I should mention that 2-d graphical functions like GUI_DrawEllipse work fine, but colors are damn wrong.

By the way, does anybody have an initialization code for SSD1963, so I can check mine with that?

[sarhangpour]

Posted on July 22, 2014 at 21:04

Still no progress here! I doubled checked every wire, compared with schematics that could be found on the net, everything is as it should be.

I switched from emWin to STemWin (remembered to eable CRC clock), same results. fonts are OK, Circles, etc. drawn OK, but colors...

I checked for any possibility of hard fault in STM32, no hard faults there.

I tried to chenge the color of a region of my LCD with a low level code, without using emWin routines:

void SSD1963_SetPoint(U16 x,U16 y,U32 point)

{

unsigned char rcode,gcode,bcode;

rcode = (unsigned char)(point >> 16);

gcode = (unsigned char)(point >> 8);

bcode = (unsigned char)point;

  wr_cmd(0x002A);

wr_dat(x>>8);    

wr_dat(x&0x00ff);

wr_dat(799>>8);    

wr_dat(799&0x00ff);

  wr_cmd(0x002b);

wr_dat(y>>8);    

wr_dat(y&0x00ff);

wr_dat(479>>8);    

wr_dat(479&0x00ff);

wr_cmd(0x002c);  

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

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

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

}

Using the above code, I draw a colored bar on the LCD, when I set the color(referd to as 'point' in the above code) to 0xFFFFFF (white) LCD hangs again!

At this moment I'm quit sure that emWin and STemWin are not causes of the problem.

Is there a chance that my FSMC initialization is incorrect? I tried to increase set up times, etc. but same results obtained.

I thing I should test with another set of LCD+SSD1963, any suggestions about what to do?

[sarhangpour]

Posted on July 23, 2014 at 18:36

I attached another ssd1963 driver to my stm32, same resuls! So, the driver is OK...

[sarhangpour]

Posted on July 23, 2014 at 21:22

Progress:

I found some information about the driver board: connection between ssd1963 and lcd panel is 18 bits width, the first parameter of set_lcd_mode (0xb0) was set as 0x0020, which refers to a 24 bit connection, I changed it to 0x0000 (actually I need to set bit A5 of the first parameter to 0, instead of 1).

By doing this, colors are shown OK, black is black, yellow is yellow etc. but...

The system hangs when I want to change color to GUI_WHITE! so hanging persists...

[Tesla DeLorean]

Posted on July 23, 2014 at 21:29

I'm not sure why writing 0xFFFFFF to the memory interface would cause the STM32 to hang-up. Where exactly is it hung-up? In the driver looping on some status bit that's stopped changing?

What about 0xFEFEFE? Is 0xFFFFFF special cased as transparent?

[sarhangpour]

Posted on July 23, 2014 at 22:48

Dear clive1,

Sorry there is a misunderstanding:

STM32 does not hang-up, it's SSD1963/TFTLCD (not sure which one) that hangs up.

I did a test to check if STM32 hung-up:

GUI_SetColor(GUI_WHITE);

GUI_Init();

(other graphical functions)

As you see, I re-initialize GUI after the mess of GUI_WHITE shows up on LCD, and things get beck to normal. So, I deduce that STM32 does not hang-up, because it's able to re-init the SSD1963.

I checked with 0xFEFEFE, the effect is just like 0xFFFFFF (LCD shows messy lines, fades slowly into a random color, and nothing is shown anymore). 

Also, I should mention again that the same thing happens if I use a command like GUI_CURSOR_Show((), very confusing.

Comparing different SSD1963 initialization codes, I found a very substantial difference here:

code 1:

...

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);

...

code 2:

...

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

wr_dat(TFT_HSYNC_PERIOD&0X00FF);

wr_dat(((TFT_HSYNC_PULSE + TFT_HSYNC_BACK_PORCH)>>8)&0X00FF);

wr_dat((TFT_HSYNC_PULSE + TFT_HSYNC_BACK_PORCH)&0X00FF);

wr_dat(TFT_HSYNC_PULSE);

wr_dat(0X0000);

wr_dat(0X0000);

wr_dat(0X0000);

...

Both codes are command 0xB4 (set horizontal period)

the first one does work for me, second one does not

. As you can see, the last 3 parameters are set to 0 in the second code, while the first code is just setting the last param to 0. 

Correction: Both codes worked, the second code worked when I chose different values for its params  (last 3 params still 0). Anyway, White is still messy!

Same sort of difference in 0xB6 (set vertical period) exists. Is there any documentation about these params, what they are and how they should be calculated?

I strongly suspect that there are still some errors in my SSD1963 initialization code...

[sarhangpour]

Posted on July 23, 2014 at 23:28

As a last try for tonight, I upload a photo that shows three bars, each supposed to be a gradient from 00 to FF of R and G and B.

Only Red seems to shows an acceptable gradient, G and B are very strange...

[Tesla DeLorean]

Posted on July 23, 2014 at 23:34

What examples does the panel vendor provide?

[Tesla DeLorean]

Posted on July 23, 2014 at 23:37

Like you have the bit boundaries/mode wrong.

You still writing 48-bits?

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

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

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