Re-initialize every 10 seconds to repair pixel instability

[dgoth]

We're using a 122 x 32 LCD device for All Shore Industries (PN: ASI-N-1223AS-GE-AWD/W). This device is controlled with the Aslic AX6121 LCD Driver IC.

We've shipped several thousand of these displays in our product, and have observed several instances of intermittent pixel instability where the position the text shifts substantially, segments of the display block out, or the pixels displayed are heavily scrambled. Typically, the device must be power-cycled to clear the pixel instability condition.

Our engineering team has been unsuccessful in eliminating this instability condition with standard hardware / software solutions.

One option that we're considering is to run the device initialization routine, repeatedly, about once every 10 seconds, such that if the device does latch-up, it automatically clears. So far, we haven't observed any downsides during our testing.

Does anybody see a problem with repeated LCD device initializations? Are there any known problems related to reduced MTBF or long-term reliability with this action?

Anybody have other recommendations regarding solutions for this type of instability?

Any help is very much appreciated.

Thanks.

Crystalfontz LCD Blog

Looking for additional LCD resources? Check out our LCD blog for the latest developments in LCD technology.

 

[CF Tech]

Other than the flicker that would be caused (possibly annoying to the user), I cannot imagine that there would be any trouble initializing the display repeatedly.

Typically, if a display loses its state, it would be related to:

1) Noise on Vcc (try soldering a 0.1uf || 1.0uf low ESR capacitor right at the pins of the display as a debug measure).

2) Noise, bouncing, or extremely slow transitions on the "E" line. You can look at the E line at with a 'scope at the display. If there is bouncing, a series terminating resistor on E or a shorter cable may help.

3) Failing to meet timing for the controller.

4) Noise on the reset line--it would have to be floating or connected to a very high-impedance for this to be much of a possibility.

Things to try:

If you do not update the display, does it still lock up or get scrambled?

If you shut off all the other stuff in your product that you can to reduce noise, does it still lock up?

If you force "long" (1mS) delays everywhere in the display routines, does it still lock up?

We might be able to cross the display to one of our parts, you can write support@crystalfontz.com with a link to or a copy of the data sheet. If nothing else, you could put one of our CFAG12232 displays electrically in the circuit (it is not a match physically) for testing. That could help point the finger towards your circuit or the display.

 

[MPOLL]

Cross for SED1520

I’ve been told that the S-MOS SED1520 Driver IC found in your CFAG12232 is no longer available from the Factory. Are you still shipping CFAG12232 with the S-MOS/Seiko SED1520? If not, what part have you crossed? Since our display switched from the SED1520 to the ASLIC AX6121, we have been observing screen anamolies that I feel are due to ASLIC having a slight bug (Read Modify Write mode comes up active and requires an end RMW command). Any thoughts on this?

 

[CF Tech]

I guess I am confused which controller is loaded on the parts (somebody knows, it is justa apperently not me). I will have to consult our factory engineer to get that issue cleared up. In any case, it is either a SED1520 or the ASLIC, which is supposed to be "SED1520 compatible".

Whichever it is, it would still give dgoth a second data point to use in trying to debug the situation.

 

[CF Support]

Our modules also use the Aslic IC compatible with the SED1520.

I also know that there is a supply problem in general with compatible controllers.