JLX256160G dim display issue

[wjgray3]

I have recently purchased a JLX256160G-922 LCD display with a ST75256 controller. I am using a Nano RP2040 processor, and a HW I2C interface, full buffer.
At first, I thought that there was a problem with the Olikraus u8g2 constructor, because I could not see any image on the display after many hours of checking everything. I even went to the Hello World basic test. No joy. I then found a contrast checker on the github, and implemented it. Then I could see an image for some values, barely. I set the contrast to the best value in my code. My code does correctly talk with the display, and the image is presented as I designed it., so hats off to olikraus and others for creating such a tool as u8g2. However, the display is extremely dim. Try as I might, I cannot determine how to make the image brighter. The backlight works fine. The image is just extremely dim. Almost not visible from straight on. Barely visible at 6oclock about 30 degrees off perpendicular. Using the ST75256 reference manual, I have adjusted via a sendF command the internal Vo from minimum to maximum and no difference. Has anybody else experienced this with a JLX display and resolved it? How? Perhaps the display was just defective from the start.
Any constructive advice welcome. Thanks.

[olikraus]

Can you execute the page buffer ContrastTest example ? Will you see something there? If not: please sent a picture of your display setup/ wiring.

[wjgray3]

Yes, the page buffer contrastTest example executes. As I stated above, the pixel image is just extremely dim. The most visible value for the contrast setting is between 175 and 230.
I have written other code and now set the display contrast to that value in that code. All the code compiles and executes, and the display I generate is presented on the LCD. The contrast between the "on" pixels and the "off" pixels is not much so the image is just really dim. So, I think that the wiring is all right, because I get the image as designed, with lots of text numbers, and discs, and lines. They are all in the right place. Just dim.

The datasheet indicates that the backlight can be driven up to 5V, and I've taken it there. 43mA of current through the backlight circuit at that voltage. There are two 100 ohm resistors in parallel in the anode trace on the circuit board of the LCD, forming a 50 ohm resultant resistance. The Vf of the backlight is ~2.85V. At the 5V applied level to the backlight circuit, the backlight is bright, a little brighter than at the 3.3V level, but the image presented by the pixels that are "on" is really dim. There is not much difference between driving the backlight at 5V or 3.3V in its brightness, and almost no difference in how much contrast there is for the "on" pixels. I am driving the digital part of the LCD at 3.3V from the Nano RP2040. Since the interface seems to be working fine, I believe the wiring is all correct. I am just wondering how to make the contrast between "on" pixels" and "off" pixels more pronounced.

[olikraus]

A high voltage is required for proper contrast. Usually this voltage is generated by a charge pump, which in turn requires several capacitors. How does the back side of your display look like? Why are so many wires? Is there any datasheet of exactly this display?
Can you send a picture of the backside and the full wiring?

[wjgray3]

I've attached pics of the setup.
The I2C connection documentation for this display says 16 of the 20 pins are required to be connected to something. Vdd, Vss, SCK, SDA, and the rest are either VDD or VSS. I am powering it at 3.3V for Vdd
There is a data sheet, and the one I have is written in Chinese. But numbers are the same in English and Chinese and I can figure out the application from experience.

There are capacitors soldered on the back side.
I ordered a display that required 3.3V. It is possible that they sent me one that requires 5V.

I don't see any markings on the display that would clue me in as to which they sent.
It seems to be communicating well at 3.3V, so I am reluctant to try 5V for the digital pins. I have independently test powered the backlight circuit with a 5V supply, and it makes the backlight just a bit brighter, but it seems that the contrast doesn't change much, so I've left it at 3.3V.

[olikraus]

Oh, one more question: which u8g2 constructor did you use?

[olikraus]

Here is a suggestion: Lets take the ContrastTest example again.
Insert the following command in setup() procedure after u8g2.begin() to change the LCD Bias ratio

u8g2.sendF("ccaaa", 0x31, 0x32, 0x00, 0x01, 5);

Instead of last arg "5" you can also use any other number from 0 to 5.
Will the picture be better with any of the values 0 to 5?

BTW: It still would be good to know, which BIAS ratio is suggested by the display vendor.

[wjgray3]

Thanks. I tried what you suggested. That didn’t work. Still very low contrast. I tried all the options, from 1/14 to 1/9 bias ratio. The spec sheet, which I am attaching, says to use 1/14 bias ratio in one place, and 1/13 in another. Some is in Chinese, but you can determine the important info. The ST75256 controller info is identical to a Sitronix controller datasheet, so I have that in English. One thing is a little unusual perhaps. It is a Chip on Glass display design, but it should still work with good contrast. I’ve tried everything I can think of. Some of those things are shown below in the setup code I’ve enclosed.. I wondered if the constructor establishes many of the options I’ve recreated below with all the sendF functions. If so, I may be redundant, but since I cannot find what the constructor actually does for this controller, I decided to force them to be what I wanted with the sendF commands and data. Some of the options may also be the default, but I set them anyway to be sure. This code is the last bit I tried. 17V Vop and 1/13 bias. The display still looks like it did in my prior photos. Very poor contrast. I’m on the verge of giving up and just buying another display, thinking that this one is defective. I’ve even written to JLX for advice. I’ve tried lots of things, including this code. The constructor I used is at the top. U8G2_ST75256_JLX256160_F_HW_I2C u8g2(U8G2_R0, /* reset=*/ 6); // End of constructor list void setup(void) { u8g2.begin(); u8g2.sendF("ccc", 0x30,0x94,0xae);// Ext Cmd 1, Sleep Out, Display Off delay (50); u8g2.sendF("ca", 0x20,0x0b);//Vb, Vr, Vf all ON u8g2.sendF("caa", 0x81,0x0f,0x05);// Set Vop = 17v u8g2.sendF("ccaaa", 0x31, 0x32, 0x00, 0x01, 0x01); // Ext Cmd 2, Analog Cir Set, Booster Effic = 6KHz, Bias = 1/13 u8g2.sendF("ca", 0x51, 0xfb); //Booster level x10 u8g2.sendF("cca", 0x30, 0xf0, 0x00); //Ext Cmd 1, Display mode, monochrome u8g2.sendF("caaa", 0xca, 0x00, 0x9f, 0x00); //Display control, not divide, duty set 160, frame u8g2.sendF("c", 0xaf); //display On This set of code is part of what Sitronix recommends for initialization in their 75256 controller. I’ve adjusted the Vop from 9v to 17v in 1v increments. Still the same low contrast each time. I’ve adjusted the bias in each of those voltage increments. 1/13 is best. Almost blank at 1/9. The spec sheet, which I’ve attached, says 160 duty cycle, so I set that. Anyway, thank you for your help. I’ll let you know if I ever solve it. Bill From: olikraus ***@***.*** Sent: Monday, February 27, 2023 3:35 PM To: olikraus/u8g2 ***@***.***> Cc: wjgray3 ***@***.***>; Author ***@***.***> Subject: Re: [olikraus/u8g2] JLX256160G dim display issue (Discussion #2117) Here is a suggestion: Lets take the ContrastTest example again. Insert the following command in setup() procedure after u8g2.begin() to change the LCD Bias ratio u8g2.sendF("ccaaa", 0x31, 0x32, 0x00, 0x01, 5); Instead of last arg "5" you can also use any other number from 0 to 5. Will the picture be better with any of the values 0 to 5? BTW: It still would be good to know, which BIAS ration is suggested by the display vendor. — Reply to this email directly, view it on GitHub <#2117 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/A57E2H7JNOWZWGMEVMR5TD3WZUMXZANCNFSM6AAAAAAVIGNURA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

…

-- This email has been checked for viruses by Avast antivirus software. www.avast.com

[wjgray3]

JLX256160G-922 datasheet.pdf

[olikraus]

I may be redundant, but since I cannot find what the constructor actually does for this controller

The init code is here:

u8g2/csrc/u8x8_d_st75256.c

Lines 1051 to 1121 in 3d41860

	static const uint8_t u8x8_d_st75256_256x160_init_seq[] = {
	U8X8_START_TRANSFER(), /* enable chip, delay is part of the transfer start */
	U8X8_DLY(20),
	U8X8_C( 0x030 ), /* select 00 commands */
	U8X8_C( 0x094 ), /* sleep out */
	//U8X8_C( 0x030 ), /* select 00 commands */
	U8X8_C( 0x0ae ), /* display off */
	U8X8_C( 0x031 ), /* select 01 commands */
	U8X8_CA( 0x0d7, 0x09f ), /* disable auto read */
	//U8X8_C( 0x031 ), /* select 01 commands */
	U8X8_C( 0x032 ), /* analog circuit set */
	U8X8_A( 0x000 ), /* code example: OSC Frequency adjustment */
	U8X8_A( 0x001 ), /* Frequency on booster capacitors 1 = 6KHz? */
	U8X8_A( 0x000 ), /* Bias: 1: 1/13, 2: 1/12, 3: 1/11, 4:1/10, 5:1/9 */
	//U8X8_C( 0x031 ), /* select 01 commands */
	U8X8_C( 0x020 ), /* gray levels */
	U8X8_A( 0x01 ),
	U8X8_A( 0x03 ),
	U8X8_A( 0x05 ),
	U8X8_A( 0x07 ),
	U8X8_A( 0x09),
	U8X8_A( 0x0b ),
	U8X8_A( 0x0d ),
	U8X8_A( 0x10 ),
	U8X8_A( 0x11 ),
	U8X8_A( 0x13 ),
	U8X8_A( 0x15 ),
	U8X8_A( 0x17 ),
	U8X8_A( 0x19 ),
	U8X8_A( 0x1b ),
	U8X8_A( 0x1d ),
	U8X8_A( 0x1f ),
	U8X8_C( 0x030 ), /* select 00 commands */
	U8X8_CAA(0x75, 0, 0x28), /* row range */
	U8X8_CAA(0x15, 0, 0xFF), /* col range */
	//U8X8_C( 0x030 ), /* select 00 commands */
	U8X8_CA( 0xbc, 0x00 ), /* data scan dir */
	U8X8_A( 0xa6 ), /* ??? */
	//U8X8_C( 0x030 ), /* select 00 commands */
	U8X8_C( 0x00c ), /* data format LSB top */
	//U8X8_C( 0x030 ), /* select 00 commands */
	U8X8_C( 0xca ), /* display control, 3 args follow */
	U8X8_A( 0x00 ), /* 0x00: no clock division, 0x04: devide clock */
	U8X8_A( 159 ), /* 1/160 duty value from the DS example code */
	U8X8_A( 0x20 ), /* nline off */
	//U8X8_C( 0x030 ), /* select 00 commands */
	U8X8_CA( 0x0f0, 0x010 ), /* monochrome mode = 0x010*/
	//U8X8_C( 0x030 ), /* select 00 commands */
	U8X8_CAA( 0x81, 0x18, 0x05 ), /* Volume control */
	//U8X8_C( 0x030 ), /* select 00 commands */
	U8X8_CA( 0x020, 0x00b ), /* Power control: Regulator, follower & booster on */
	U8X8_DLY(100),
	U8X8_END_TRANSFER(), /* disable chip */
	U8X8_END() /* end of sequence */
	};

[olikraus]

Looking at the PCB: The LCD voltage is generated by a charge pump, probably with the help of C1, C2 and C3. If those caps are not corrcetly soldered, then maybe the charge pump fails to create the LCD voltage. Maybe just reheat the solder pads for the mentioned caps.

[olikraus]

This is the suggested init sequence from the display datasheet:

void initial_lcd()
{
RST=0;
delay(100);
RST=1;
delay(100);
transfer_command_lcd(0x30); //EXT=0
transfer_command_lcd(0x94); //Sleep out
transfer_command_lcd(0x31); //EXT=1
transfer_command_lcd(0xD7); //Autoread disable
transfer_data_lcd(0X9F); //
transfer_command_lcd(0x32); //Analog SET
transfer_data_lcd(0x00); //OSC Frequency adjustment
transfer_data_lcd(0x01); //Frequency on booster capacitors->6KHz
transfer_data_lcd(0x01); //Bias=1/13
transfer_command_lcd(0x20); // Gray Level
transfer_data_lcd(0x01);
transfer_data_lcd(0x03);
transfer_data_lcd(0x05);
transfer_data_lcd(0x07);
transfer_data_lcd(0x09);
transfer_data_lcd(0x0b);
transfer_data_lcd(0x0d);
transfer_data_lcd(0x10);
transfer_data_lcd(0x11);
transfer_data_lcd(0x13);
transfer_data_lcd(0x15);
transfer_data_lcd(0x17);
transfer_data_lcd(0x19);
transfer_data_lcd(0x1b);
transfer_data_lcd(0x1d);
transfer_data_lcd(0x1f);
transfer_command_lcd(0x31); //EXT=1
transfer_command_lcd(0xf0); //此指令比较重要,不加此指令升压会慢 0.5s
transfer_data_lcd(0x0f);
transfer_data_lcd(0x0f);
transfer_data_lcd(0x0f);
transfer_data_lcd(0x0f);
transfer_command_lcd(0x30); //EXT=0
transfer_command_lcd(0x75); //Page Address setting
transfer_data_lcd(0X00); // XS=0
transfer_data_lcd(0X28); // XE=159 0x28
transfer_command_lcd(0x15); //Clumn Address setting
transfer_data_lcd(0X00); // XS=0
transfer_data_lcd(0Xff); // XE=256
transfer_command_lcd(0xBC); //Data scan direction
transfer_data_lcd(0x00); //MX.MY=Normal
transfer_data_lcd(0xA6);
transfer_command_lcd(0xCA); //Display Control
transfer_data_lcd(0X00); //
transfer_data_lcd(0X9F); //Duty=160
transfer_data_lcd(0X20); //Nline=off
transfer_command_lcd(0xF0); //Display Mode
transfer_data_lcd(0X10); //10=Monochrome Mode,11=4Gray
transfer_command_lcd(0x81); //EV control
transfer_data_lcd(0x20); //微调对比度的值，可设置范围 0x00～0x3f
transfer_data_lcd(0x05); //粗调对比度，可设置范围 0x00～0x07
transfer_command_lcd(0x20); //Power control
transfer_data_lcd(0x0B); //D0=regulator ; D1=follower ; D3=booste, on:1 off:0
delay(20);
transfer_command_lcd(0xAF); //Display on
}

Setup looks quite similar to the current u8g2 setup (except that u8g2 uses 1/14 Bias compared to 1/13 Bias here). Also the 0xCA command is the same.
The only strange sequence is this:

transfer_command_lcd(0xf0); //此指令比较重要,不加此指令升压会慢 0.5s
transfer_data_lcd(0x0f);
transfer_data_lcd(0x0f);
transfer_data_lcd(0x0f);
transfer_data_lcd(0x0f);

More and more i also think that there is a hardware issue. As mentioned above, resoldering C1, C2, C3 could fix the issue. Maybe also one of the capacitors are broken and need to be replaced.

Another idea: Is there sufficient power for the display itself? I mean, even without backlight, the display and especially the chargepump will require a good amount of current. From your pictures it looks like that the complete system is powered by USB. Maybe just try with a proper power source. Moreover, drive the display with a separate power source.
One more point here: The charge pump will require a good capacitor close to the display itself. Maybe add a 1uF cap between VSS and VDD on the PCB connector itself to support the charge pump.

[wjgray3]

I tried all the suggestions. None worked. I have resoldered the three capacitors. They all measured ~1.5uF. Then I replaced all three capacitors. I provided a separate power supply (with greater than 5 amp capacity). This display draws a few milliamps at most. The rest (~40mA) is for the backlight.
The voltage supplied is rock steady at 3.3V from a LM1085 regulator and 10uF of cap filter.

Seems like an internal charge pump problem I cannot rectify, or something else.
I gave up and I have ordered another display in this size.
I have tried another display that is not the right size, but all my code results display properly there, with excellent contrast. The sendF tool is quite useful to initialize the displays exactly per their spec sheets. Thanks for that.
Thanks for your help anyway.
Bill

[olikraus]

Hmmm 🤔