What's the failure mode for the uOLED display?

Jim Boemler

I've had a uOLED-128-G1 in use for a week on a new project.· I did spot the caveat about powering down the display in software before removing power (a dumb-as-a-rock design, IMHO).· But since the sequence requires software, and I was starting up a fresh project, I've ended up with dozens of unannounced power removals in the process.· Last night, the display didn't light up at all at power-up, with no signs of problems beforehand.· The software interface seems to still work (it responds with an ACK to auto-baud input), but nothing on-screen.

Is this the way these things fail when abused like this?

BTW, in the spirit of full disclosure, I did rewire the power input to my prototype board just before this happened.· But I rechecked the complete wiring (both visually and voltages) after having the problem, and it was fine -- what I mean to say is that there was no time when it got abnormal inputs before being fixed.

Thanks for any insights.· I'm thinking of just buying a new one and taking my lumps, but they're pretty pricey, and I don't want the thing to be a consumable.

jim

PS: how are others handling this software power-down requirement?· My own use is automotive, with the power switched with the ignition.· I suppose I could run two power inputs (switched/unswitched), but I'd rather avoid the extra draw.· What I had in mind was to use a pin to sense raw battery power, and use the last of the capacitor on the regulated side to do the power-down.· Unfortunately I haven't finished it yet.
·

whicker

Requiring software to send a sequence to shut down the display before removing power just reeks of lazy design.

And you're exactly right: I am wondering what will go wrong if you don't? Will a pixel, a row of pixels, the whole screen, the screen controller, or just data in the flash memory get damaged?

Jim Fouch

I also have a 160 that just stopped working after it had been working for quite some time. I haven't been able to see it light up, but can see a very faint image on the screen. Not sure if it's from not being shut down correctly or some other issue.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jim Fouch

FOUCH SOFTWARE

Jim Boemler

Interesting! I looked again real close, and I too can see a faint image; didn't even notice it before. Looks like I have an identical failure mode to yours. Thanks, that actually helps -- at least now I can be certain it really is the display (probably drivers) gone bad. Of course that in turn leads me to want to use a different display. [noparse]:([/noparse]

How did you handle the software shutdown requirement, Jim?

jim

Fred Hawkins

It's my understanding that even the demo program risks this happening. It's a mere loop that is stopped by removing power. So guidance from 4d on this aspect has been, so far, slim.

There's a thread here that discusses using a large capacitor to keep a prop running after its usual power is removed, the point being to allow housekeeping before the prop shuts down. Perhaps that could be used to keep the µOLED going while it formally shuts down.

Another thread which might useful: http://forums.parallax.com/showthread.php?p=693243

Post Edited (Fred Hawkins) : 9/1/2008 10:32:05 PM GMT

Jim Boemler

Thansk Fred, sounds like the same idea. What I was going to do as a measurement was to start a counter when power-fail is discovered (in my case a resistor divider from 12v supply to a Propeller pin), and write the counter value to EEPROM. When you power up again, the value in the EEPROM tells you how long the processor ran after power loss. I haven't done the EEPROM storage yet, but I've turned on an LED, which then goes out when the 3.3v is finally gone. It's a flash; short, but I would guess on the order of 50ms. Should be plenty of time for an orderly shutdown of most things. This was with a 1000uf cap on the 5v input to the Propeller. Sensing was to the 12v regulator input, which intentionally had no filter cap.

You're right about the uOLED driver -- no shutdown provision at all. One of the early things I did was to code a manual shutdown into my menu system, so that during development I could avoid extra abuse, but due to various software errors it still had to be powered-down only in hardware many times. Too many, it seems, although its last working shutdown (and many before that) was done with software.

Bottom line, it looks like these things are fragile -- more so than a product like this should be, in my opinion. For reliable operation this will need a new driver, with its own very different serial driver. If I can get done writing it without it costing a second display, I'll post it.

jim

Duffer

A thread posted in the 4D Systems forum entitled: "Power Down Sequence Warning Explained", located here:

http://www.websitetoolbox.com/tool/post/4d/vpost?id=2944308

might be of some help. At least it points out that an uncontrolled shutdown can be harmfull to almost any LCD or OLED display over time and that the displays are not capable of mitigating the danger on their own (unlike the power on sequence requirements which are normally handled by the display formware).

Duffer

Jim Boemler

Thanks Duffer. Good to see 4d responding. I'll be posting some more questions, both here and on their forum.

BTW, I didn't measure the time available as I described, but I made a quick and dirty test by adding a delay before turning on the LED at power-down time. I could still see a flash with a 15ms delay, but nothing with a 20ms delay. The problem (well, the first-level problem at least) is that the OLED wants 100ms of power after issuing the software command; that would take a MUCH larger cazapitor. I might have to revert to the switched/unswitched power, but that also means an extra lead to the display head, which means different connectors and custom cables. Groan. [noparse]:([/noparse]

jim