Wow, that's embarrassing -- the answer was already right there, in a thread I had started, no less...
That's what happens when I get back to work on a side project after several months have gone by. Sorry about that. However, after a lot more investigation today, it appears there is still a problem to be resolved with the CFAG160160B modules.
A few days ago I discovered Vee blown on a module that has been in one of our engineering prototypes for several weeks, working fine. Nobody had stuck their hands in it, nothing had been changed, etc. One day Vee was there, the next day it was blown. We had simply been powering up our prototype, flashing code to the processor on our board, running the code (which resets the lcd module when it starts), and eventually powering it down.
With my investigation today, I believe I have tracked the blown Vee down to Vo (pin 4) drawing too much current after these CFAG160160B modules are powered up but *prior* to the module being initialized by dropping/raising the reset line (pin 10).
While 15mA capacity on Vee is plenty, more than enough, this is only true as long as Vo doesn't decide to draw more current than it should. The typical current on Vo is not actually given in the datasheet, at least not that I see, but let's call it Ivo.
My measurements today show that after the module is powered-up, then initialized, and everything is running correctly, Ivo is somewhere between 2-3mA, typically around 2.75mA when the bias is set so the screen is readable at room temperature. Running Vee through my PWM-controlled circuit to control Vo, I see a max of about 4mA pulled through Vee. So far, so good, I'm well below the 15mA max current through Vee.
However, when I power up the module but do not run the code on my processor, the reset line is never de-asserted/asserted to reset the module. In this state, Ivo is 17-18mA! Because of the load Vo is presenting, the current drawn from Vee is between 19-20mA. If I take a long time between power-up and resetting the module (for instance to flash new code, set breakpoints, pre-set some memory contents on the board, or other things related to using the prototype for firmware development) then Vee will eventually get blown because Vo is asking it to source too much current the entire time the module is powered up but not externally reset.
I put together a quick test on a breadboard using the potentiometer-based bias control approach shown in the data sheet, with the values shown. The same thing happens: After the module is powered up, but before it is reset, Vo is drawing so much current that it causes Vee to source well above 15mA through the simple potentiometer-based circuit.
So: From my perspective, I would see this as a design issue with the CFAG160160B modules. They should not power up in a state that causes them to operate outside of their own acceptable parameters prior to some external circuit de-asserting/asserting the reset line on pin 10. It might be a long time before an external circuit can get around to doing that (especially if it's software controlled). I realize there can be other perspectives on this, but I don't think this type of product should risk damaging itself in this way. Nor should it place the burden of avoiding damage on the external circuit designer, just because it doesn't power itself up to a sane operating state.
Not sure what I'm going to do at this point, unfortunately. Our hardware design is supposed to be locked down now. I guess I'm going to have to figure out some way to keep Vo disconnected from the circuit until after the processor has reset the module, if I can get the change incorporated and turn the board one more time.
CF Tech and cosmicvoid, I appreciate you both jumping in on this over the holiday. All further thoughts are appreciated, especially if you disagree with my characterization of this as a design issue with the modules. Other than this problem, we have been extremely happy with these modules and continue to drive towards commercializing a product that incorporates them (in a side-project kind of a way...).
Thanks!
