Questions? Call us: +1 760-918-6722

Soak test causes random blanking of units

We've just produced our first production run using these displays, and I ran 9 units overnight and four failed.... which is bad as we're under immense pressure to ship these (of course :). This is the first time we've seen this issue.

The details/symptoms are :
- The displays simply blank, at a random point in time, from 4mins to several hours, although the application still runs fine.
- The Vlcd voltage has sagged considerably (from normal 17.2V to 10.7V with a 2V p-p ripple...
- Applying an external 17.2V supply to the Vlcd causes the display to miraculously reappear :)
- Restarting the unit removes the issue and all is fine, for a while at least...

It appears to us that the issue is the booster circuit loading and sagging. What we haven't done is prove this, and this is where I am hoping someone else may have seen or have some experience with this.

Circuit is a 6x boost from 3.3V, using 1uF caps. 8080 8-bit bus interface (to ARM7).
Have tried retuning the booster and osc settings for the highest output voltage, which (a little unexpectantly) is with booster at '0' (3kHz) and osc at '0' (12.7kHz). Managed to squeeze another 0.3V out of vlcd but this has not solved the issue.

Next attempt is to increase the 5x boost caps from 1uF to 2.2uF. If that doesn't work we're still short a plan C.

Other thoughts in the background :
- are somehow accidentally (ie noise on a dataline) sending a configuration command to the LCD. I can't think of anything that would cause these symtpoms though. (ie, 2v p-p ripple...)
- the LCD is being reset. I don't think this is the case as the data is still present when applying external voltage.
- ?

If anyone has any thoughts on this that would be greatly appreciated.

Replies

dtechsupport's picture
dtechsupport
November 21, 2009

Basically the IC charge pump can't handle the condition of all pixels on due to the S128240D panel being so large. Our most recent spec, version 1.1, reflects this on page 3 of 21. Please also note, the Sitronix ST7529 spec makes comment to this as well on page 33 of 86.

Guest's picture
Guest
November 21, 2009

Are you essentially saying then, that the driver IC displaytech has designed into this LCD is not fit for purpose?

dtechsupport's picture
dtechsupport
November 21, 2009

No, but there are limitations that are known by the IC supplier: Sitronix as well as Displaytech. The LCD will work under certain conditions, but it is necessary for you to determine if it will work in your application. You can also reference the thread about optimizing contrast, there are some tips in there as well. And some images of using the grey scale functionality which definitely is loading the screen heavy.

Guest's picture
Guest
November 22, 2009

I may have a few ideas - would you be up to running a test?
Some questions first...
1) Are you displaying any grey-scale images, or are you just using 100% black (0xff) and 100% 'white' (0x00) for all your pixels?
2) Does the software change the display image at any time during the test, or is the target image static?
More specifically is what the display should be showing identical between the post reset state (i.e. when all is working) and the post fail state (i.e. when it has failed, and then you've brought it back by applying an external bias)?
The following are diagnostic tests - not true solutions...
First test
When the issue occurs, could you set the entire display memory to 0x00, then re-paint the target image - without resetting the display?
By entire memory, I mean the even the areas that aren't on the visible section.
This is [0..254] x [0..159] set to 0x00
For example
You could link the 'set-to-zero-and-re-paint' code to a push-button.
First verify that if the display is working
Then hit the button and verify it keeps working.
Then wait for the image to fade.
Then verify that you can recover it by applying the external bias
Then remove the external bias
Then hit the button
Does this recover the image?
Second test
If the first test works, then again wait for the problem to occur, but instead of clearing out the whole display ram, just clear-out the ram areas that are not viewable.
I.e. if your image is oriented with the fpc at the top, then
The display ram is [0..254] x [0..159]
The viewable area is [0..239] x [16..143]
The part of the display ram this is not viewable is:
[0..254] x [0..15] and
[0..254] x [142..159] and
[240..254] x [0..159]
Please let me know the results of the tests - if one or both recover the image then we should be able to resolve the issue.
If they do not resolve the issue, then could you post some pictures of the image you're displaying, and of when you recover it, and perhaps some of the code to create the problem.
Martin

Guest's picture
Guest
November 26, 2009

In reponse to your questions, the areas of the display not written to were already blank, and once the external supply was added, everything ran fine, ie, parts of the screen that update every second were updating fine. There were no issues with the data being displayed, only that you couldn't see it!
However, we appear to have now resolved this problem.
- Increased charge pump caps to from 1uf to 2uF
- Reduced frame oscillation rate by tweaking OSC frequency and divide-by counter until the screen was only just not visibly 'flashing'.
- Tweaked booster settings for max Vlcd.
So, basically, everything I could to either directly increase the performance of the charge pump or to reduce the load on it. From all of the above, managed to increase the charge pump output by another 1.7V, and miraculously don't have any more failures! 12hr soak tested 10 units fine, and no more failures since going to production. Hope it stays like that!