Winstar WG12232O LCD

[Unixon]

Hi,

I'm trying to make use of WG12232O graphical LCD in my project but it doesn't want to show me anything.
The prototype device is based on ATmega1280 micro that drives the LCD directly from it's ports by parallel bus,
the firmware uses u8glib library (LCD driver is SBN1661G) + some of underlying code from Arduino libraries.
The whole LCD is hooked now to logic analyzer so I can verify how the display driver protocol is implemented by the u8glib library.
As far as I could check this, the data on the display bus looks correct and I even can read in the logic analyzer output what I'm putting on the display matrix.
However, the LCD doesn't show anything, and what is surprising is that all pixels are "ON" from power up and not changing.
The LCD is brand new and never had been connected to any other device, the wiring is verified and correct.

Looks like I'm missing some small important thing, but I can't figure out what it is.
Does anybody have experience with WG12232 displays and especially the recent "O" revision ?

[Unixon]

However, there are things about which I'm not sure that they're exactly correct.
Popular revisions of WG12232 display are "A","C","D","E" are all somewhat different from one to another.
WG12232 could carry one or two driver IC dies, "O" revision is supplied with two Avant SBN1661G.
There are few signals in the interface that change behavior between revisions.

"A") Die selection signals "CS1","CS2" active on falling edge or low level;
"C") Die selection signals "CS1","CS2" active on falling edge or low level; Needs positive "E" enable signal + 2kHz external clock on "CL".
"E") Die selection signals "CS1","CS2" active on rising edge or high level; Needs positive "E" enable signal + 2kHz external clock on "CL".
"J") Die selection signals "CS1","CS2" active on rising edge or high level; "CL" is used for negative voltage supply.
"D") Has no die selection signals "CS1","CS2", instead of this it has individual strobes "E1" and "E2" which are active presumably on rising edge or high level.
and finally
"O") Die selection signals "CS1","CS2" active on falling edge or low level; Needs positive "E" enable signal. Probably needs 2kHz external clock on "CL", this is under question.

I'm not sure about the polarity of "CS1","CS2","E" for WG12232O and if it really needs 2kHz on "CL" pin.
Also, the initialization sequence is under question: u8glib issues some commands that seem correct, but I don't know if that is enough for "O" revision.

[Unixon]

What's puzzling me is that "A/C", "E/J", "D/D1" are described in couples and it is clear which option applies to which revision. The datasheet for "O" revision keeps description of optional connections for "E" and "CL" but there's only one version of display so I can't tell if these options are applicable or not.

I tried to do it few ways: clock data by "CS1"/"CS2" while keeping "E" high, clock data with "E" while keeping "CS1"/"CS2" low or high depending on what die is selected, supply 2kHz to "CL" pin from signal generator, tried to invert signals. Nothing works.

Winstar site page dedicated to graphical LCD displays: http://www.winstar.com.tw/products_detail.php?CID=18
Avant SBN1661G datasheet: http://www.allshore.com/pdf/Avanti%20SBN1661G.pdf

[ruffy91]

If the pixels are always black your voltage Vo on pin 3 seems to be off. Have you tried to put a 10k pot between Vdd and Vss and connecting the wiper to Vo? You can adjust the contrast with this.

[Unixon]

If the pixels are always black your voltage Vo on pin 3 seems to be off. Have you tried to put a 10k pot between Vdd and Vss and connecting the wiper to Vo? You can adjust the contrast with this.

No, the voltage at Vo pin is just fine, a pot attached to Vo perfectly regulates the contrast.

[Unixon]

I think I found a couple of things being wrong. Looks like the problem is in the initialization procedure. By careful investigation of the logic analyzer output I found that some bits of command bytes are not set as they should, but a more surprising thing is that after the initialization command sequence is completed, something issues another reset pulse which voids everything. Few milliseconds later, when the firmware tries to send some actual data to the display matrix, it is already in unprepared state as it was after power-up.

I suppose that either u8glib switches the reset pin into input mode when it doesn't need it and it then the pin is pulled low by the circuit (it should be low at power-up, so I decided to go with just a single pull-down resistor rather than a proper RC circuit of a pull-up resistor and a capacitor) or something else in the firmware gets in the way and switches the pin to active low state.

Considering unset bits in command bytes I'm not sure if the is because of firmware or just a plain mechanical contact problem, need to check this too.
I hope there's nothing else wrong with this LCD.

[amyk]

122 x 32 is an unusual resolution - usually it's 128 x 32 or 128 x 64, but since an SBN1661G is 61 x 16, there's probably two of them in the module.

There are different variations of the SBN1661G - figure out which one you have.