Sharp LM32P07 LCD driver issue

[gkmaia]

I am trying to fix this LCD but got stuck.

I have two of these and have been comparing both to find differences.

Both U4s are counting down from 96 cycles set by P2 and P1 HIGH @ 19khz, lowering TC to then pulse U5 1Q to the LSI LCD drivers @ 400us intervals.

I can see Q1 voltages changing from -12v to -16v when changing contrast settings but it has not visual effect on the LCD panel.

U3 op amp are slightly different, but not much. Out2 is +1.2v on faulty and +1.5v on the good one. Out4 is -15v on the faulty one and -14 on the good one. Not sure if there anything of concern here as these voltages apparently are not being used by logic threshold.

Data is flowing to the  vertical segment LSI drivers U7 and U6. I cannot find any  trace of this 4 bit data bus to the the horizontal segment drivers U1 and U2. I do not understand how these two work without getting data, just clock pulses.

In overall i would suspect my LSI drivers are faulty. But as far as I have seen when a PLC LSI driver fails just those segment fail.

In my case as nothing shows in the display that would mean at least 2 parallel drivers must have failed at the same time.

As I don’t understand very well how these drivers work I am quite stuck in order to make a diagnosis here.

Could anyone with some good experience with LCDs give me a hand here?

[Buriedcode]

How are you driving these panels?  They have no controller, or built-in negative voltage generator - at least the LM32P07 I have sitting next to me doesn't - so you must be using an external SED1335-like controller and VEE supply.  The one I have needed ~-24V on VEE, and a ~10k voltage divider to provide -16.5V on Vo in order to see the display.   If yours is producing its own VEE in the -15V sounds about right on the contrast adjust.

Two of the IC's are used to generate the M signal to regularly invert polarities in the panel to stop burn-in, most of these older 90's panels have a counter and JK flipflop for this.  The third IC will be the voltage divider quad opamp, often a LM324 or similar.

Edit: Just seen the schematic you've traced from it, which clearly shows you know all the above, sorry! 

The common drivers don't necessarily need D0-D3, at least in quite a few LCD's I have with very similar drivers, only the column drivers need the data, but some have the datalines routed to the flex cable anyway (sometimes 8 data lines, with 4 unused, as I guess they use similar flex boards for 480x320 displays or 640x480 too).

[gkmaia]

Thanks mate. I appreciate the help.

Do you know the model of these COF TABs?

If I could pin them out that would help identifying what the issue is.

[gkmaia]

WAs doing some A/B logic analysis and found a difference on U5-Q2.

On the attached images at probe label D3/2Q it is possible to see that on the faulty PCB when in LOW there are constant HIGH spikes.

While on the good PCB low is constantly low.

Any thoughts?

[Buriedcode]

From the looks of your picture, the segment drivers (the two at the bottom of the display, you call them vertical) are working, because it is driving pixels across the whole display, but only on the top half.

So its the second common driver ("horizontal"), at the bottom that has either failed, or getting incorrect signals.  Generally only the segment drivers need D3-D0, the common drivers just need clock and reset signals, although I have seen some displays where D3-D0 is routed via flex cables to the smaller boards where the common drivers are mounted - but they aren't connected to the common drivers.

I just took my display apart, and it doesn't have the same devices your has - mine has what appears to be a dedicated voltage divider chip (instead of a LM324 clone and resistors) and a dedicated LC logic (replacing the flipflop and counter to generate the M signal).  So, it seems I have a different version that is completely different.. However.... I recognize both the PCB's in the photo and the schematic, because they look almost identical to a couple of other 320x240 displays I have, specifically a WM-G3224 ( http://www.lcdinfo.com/temp/MG3224Y-1NFWbV1.pdf ).  These too use the LH1530F common driver, but I haven't yet identified the segment driver.  They also have the same devices your boards have, but with different segment drivers

In your logic analyzer output, it does look odd that the output of the second FF (Q2) has spikes that appear to be at the rising edge of Q1's output.  That isn't right, and could well be causing the lower common driver to not be selected correctly when scanning - ultimately preventing it from driving pixels in the lower half of the screen.    Or perhaps it is just interference from your probes.  If your analyzer doesn't have them, I would add some 10k pull-downs to those lines just to eliminate this possibility.

I very much doubt there is anything wrong with the 74HC74,, but if you're comfortable reworking, I don't see how replacing it would be harmful (they're cheap anyway eh). Or there is a short somewhere, perhaps along that clock line (pin 12 the main connector, pin11 on the 74HC74) or on the output (74HC74 pin 8/12).

I guess the next step would be to double check those spikes really are coming from the flipflops output, and if they are, remove U5 and check for shorts, replace U5 with a new one.

Sorry my display isn't the same as yours, same part number, same appearance (the backlight bracket and mounting holes are the same) but completely different internals. 

[gkmaia]

Thanks so much for the time taken here buriedcode. This is getting fun.

I did a few checks:

Removed HC74 and replaced with the one from the working LCD. Faulty LCD still faulty and same HIGH pulses on 2D.

While off and traces exposed I double checked my schematic and it is correct:
2Q goes to 2D
2Q- goes nowhere.
2CLK is the only to take the 75Hz oscillator, not sure for what reason.
Register 2 of the HC74 goes nowhere. Probably hooked like that as a default if 2nd register not in use?!

I can pretty much rule out any issue with the logic flow from 103 to 74 to the segment driver.

Also, if you look at the LCD running photo you will see the top row is just a solid dark, even by changing the contrast circuit it remain solid dark.

Edit: finally found the segment driver. It is an OKI M6779.

I added some logic scans of the 13 pins of CN3 of both good and bad LCDs.

Some stuff I noticed. When LOD raises at is right intervals, clock drops. When LOD raises randomly it also brings Vss up as if there was a short.

What do you make of it? Do it all point to bad COFs?

[Buriedcode]

This is getting interesting.  I'm starting to think I'm not being much help here, but as you have more than one with the same fault, I'm trying to think of the sort of fault that would cause it.  Given how delicate TCP devices and their flex PCB's can be i'm inclined to think the problem is there - but often the weak spot is its connection to the glass which would cause random rows/columns/pixels to not work, rather than the entire bottom section - but may explain the top row being permanently dark, which is indicative of no drive signal at all (if that row has lost connection).

While off and traces exposed I double checked my schematic and it is correct:
2Q goes to 2D
2Q- goes nowhere.
2CLK is the only to take the 75Hz oscillator, not sure for what reason.
Register 2 of the HC74 goes nowhere. Probably hooked like that as a default if 2nd register not in use?!

I checked another LCD I have, and just like yours, the second JK flipflop has !Q feeding back to D, is clocked by S/FLM but the output goes nowhere, and the first Flipflop is using along with the counter, to generate the M signal (Q in your schematic).  As this M signal ( which alternates the driving voltage polarity regularly to prevent polarization of the LC) can be "every other frame" so I strongly suspect that the second flipflop generates this, so it is high for one frame, and low for the next.   But there are also other frequencies it can be, and most LCD's I've seen use a counter and JK flipflop so.. I'm guessing that somewhere these is a solder jumper that can select between these two.  Hantronix had a small app note about it: http://www.hantronix.com/files/down/M_signal

So, I think those glitches on that second flipflop are a red herring.  But thats the reason the flipflop is hooked up that way.

Some stuff I noticed. When LOD raises at is right intervals, clock drops. When LOD raises randomly it also brings Vss up as if there was a short.

Those glitches on your latest plots (the faulty ones), are they not on the "good" LCD?  A lot of them look like noise glitches, from faulty connections/probes.  With that said, the zoomed in one 150us, does look like a longer pulse. 

Also, Whilst I haven't checked with an LA yet, I vaguely remember the SED1335 and similar drivers not clocking CP2 (CLK) when CP1 (LOAD/LP) is high.  So, rather than a fault, this could be just how the LCD controller is driving it.  With that said I've been wrong about quite a few things so far! And if CP2 isn't missing a pulse during CP1/LP on the good LCD than your are right - as if there is something funky going on.  If there was a short between CP2/CLK and CP1/LP then the low LP would prevent the clock from rising, and similarly when LP was high, it would force CP2/CLK high.

So far, I'm still thinking as pixels are being driven across the display but only on the top half, the segment drivers (OKI M6779 - good find!) are fine, or at least driving the pixels with voltages. Its the lower common driver that isn't being clocked correctly.  If adjusting the contrast makes no change to the bottom of the screen then these pixels aren't getting any kind of signal, so that common driver is either not getting correct power, or clocks, or is effed.   If you can, probe  U1 and U2, or just the one that controls the bottom half of the screen.  The glitches in the plots do looking worrying, but I can't see them only affecting the bottom half of the display.

[gkmaia]

As per being not of much help don’t think like that. It is all about the journey of testing and learning. If we fix it great, if not I will have learned some on the way. But so far you have most of the answers I do not have as I have less experience.

I am reading the APP note. Thanks for that.

As I am running an Agilent MSO I probed with a CH1 passive probe each of the logic pins while the LA was running. Could not reproduce any of the glitches with the passive probe.

Hooked the logic probes in different ways, directly to ICs and glitches were still there. Just to check if I was hooking it badly. Or changed the trigger type or logic threshold... but no. Something weird going  on with my logic probes. You were right. The glitches are being created by the probes. Just not sure why at this stage. I have ordered new LA probes, lets see if it persists with the new ones.

If you look at the image attached. That is a plot from the GOOD display and we can see glitches on DF channel. Same La probing issue.

I vaguely remember the SED1335 and similar drivers not clocking CP2 (CLK) when CP1 (LOAD/LP) is high.

That also does not happen if I probe directly with a CH1 passive probe. Clock is solid on both bad and good displays. That again was a glitch created by the LA probes.

So far, I'm still thinking as pixels are being driven across the display but only on the top half, the segment drivers (OKI M6779 - good find!) are fine, or at least driving the pixels with voltages. Its the lower common driver that isn't being clocked correctly.  If adjusting the contrast makes no change to the bottom of the screen then these pixels aren't getting any kind of signal, so that common driver is either not getting correct power, or clocks, or is effed.  If you can, probe  U1 and U2, or just the one that controls the bottom half of the screen.

Cool. I will do that when I get home tonight and will post the results here!

[gkmaia]

Here are the sets of scans:

Faulty CN2 scans
Good CN2 scans
Faulty U2 scans

On the scope CH0 = to pin 1, CH1 = to pin 2, ....

Also updated schematics.

[Buriedcode]

It has to be said, thats a very thorough test... its taken me about 15 minutes with a coffee to see whats what! I'm amazed you managed to hook up probes to 16 pins on theo TCP devices, the pitch must be what, 0.6mm?  Also just noticed the common driver part number - I've been looking at the LH1350F datasheet and wondering why the signals are wrong    So hopefully I'm on the ball now.

Sadly, I cannot see anything out of the ordinary.  I was hoping for something like, an input pin on U2 or U1 being grounded, but it seems its getting all the right clocks.

Edit: Bear with me, this is quite involved, and I'm not very good at explaining things.
The only thing that looks a bit odd is pin8 (pin12 in the datasheet for the MSM6778), called IO120, which is the output of the shift register.  This pin on U1 - or whatever common driver is running the top half of the display - should connect to IO1 (pin11 on schem, pin9 in datasheet) of the other driver, as they are cascaded.  But in your schem it seems both devices have pin8 connected.  IO60 and IO61 should be connected as they are, because each driver controls 120 lines.  I believe the S/FLM (also called first line marker, scan startup signal) provides a '1' at the start of a frame, that is shifted through the shift registers, selecting each line one by one.  It will be hard to probe, because it will probably be the width of an LP pulse, but only two of those pulses per frame (one per driver).  As a frame is 75Hz - 13.3ms, thats only once on the second driver, every 13.3ms.  So, that means "S" on our schem should be connected to pin11 of one of the common drivers.

I'm assuming this is just a mistake in the schem, as it was correct in your previous schem and because I don't see how they could accidentally become connected this way, and also, this would mean the pixels still get positive and negative voltage swing, (MSM6778 datasheet, page 7, shift register data = L, DF is changing every 7 lines; so pixels get V2, +3.2V and V5, -12.6V   ... = pixels will show something). This means adjusting the contrast would cause them to all be "on" with the rest of the display.

As for all the voltages and resistances, all the voltages look well within spec.  Even if you used a lower (less negative) VEE, the pixels don't require that much of a negative voltage to turn on, so "nothing" on the lower half of the display still, to me, indicates they're getting sod all.  Perhaps that driver has completely disconnected from the glass?

Again, the fact you have two displays with the same issue seems too much like coincidence to me.  I'm unsure how to proceed, because I'm not sure how I could recreate the issue.  All the signals look fine, and as you traced out the schematic with continuity tests, that would have highlighted any broken traces/connections. Out of ideas 

[gkmaia]

It will take some time to go through you email. Thanks so much for that.

I build a little hook box with 0.2mm enamelled wire. Cant hook at 0.6mm with standard leads.

The only trouble is to weld the wires to each pin to be tested when you need to test something. But with a magnifier that gets easy.

I wish I had money to spend $200 in one of those HP wedge adaptors. They are pretty cool!

[gkmaia]

The only thing that looks a bit odd is pin8 (pin12 in the datasheet for the MSM6778), called IO120, which is the output of the shift register.  This pin on U1 - or whatever common driver is running the top half of the display - should connect to IO1 (pin11 on schem, pin9 in datasheet) of the other driver, as they are cascaded.  But in your schem it seems both devices have pin8 connected.  IO60 and IO61 should be connected as they are, because each driver controls 120 lines.  I believe the S/FLM (also called first line marker, scan startup signal) provides a '1' at the start of a frame, that is shifted through the shift registers, selecting each line one by one.  It will be hard to probe, because it will probably be the width of an LP pulse, but only two of those pulses per frame (one per driver).  As a frame is 75Hz - 13.3ms, thats only once on the second driver, every 13.3ms.  So, that means "S" on our schem should be connected to pin11 of one of the common drivers.

I had time to read it in more detail now. I think i need to do a better job on the schematics for U2 and U1 common drivers. Also I will do a parallel LA of IOs for both drivers at the same time. And double check if the IO output of one of the drivers towards the IO input of the other driver and make sure the schematic is right.

That will probably give us a better understanding of what is going on. The confusion on my scan and the schematics have been of much help. I need to improve that. Will post the results tonight.

I will also apply some pressure to the ACF connection between the glass and the TAB, maybe some heat and see if that changes the data the LA captures.

[gkmaia]

I put together a new set of scans and fixed the schematic. You were right my wiring was wrong. Basically because the silkscreen on the board is inverted and that messed up. If you look at the schematics attached to this post it is now correct.

Also, as SHL is low on both U1&2 then U1-IO120 is an output that inputs on U2-IO1. There are clock IO120 pulses at the raising edge of DF but not at all of them.

I am still getting ghost signals when I connect D0 to D3 on the probe. For that reason I've made a couple scans without the data pulses so you can see it clean.

What do you think? How do the I/O shift register pulses look?

[Buriedcode]

Hi,
Again, I admire the effort you're putting into this!  Full schems of these displays are never available and often an arse to trace out.  It's pretty cool seeing how it all works.

DF here is the modulate signal, which isn't really needed to display anything, but it regularly changes the voltage levels used by the glass so the pixels don't get polarised.  It isn't part of the shift register and doesn't necessarily need to be in sync with the rest of the clocks.  So the IO120 of U1, going into IO1 of U2 should have a pulse after 120 CP pulses (the line marker).  As I mentioned in my previous post, its a bit of a sod to capture as its once per frame, right in the middle of the frame, line 120, to line 121.  But you've capture it so at least we know thats working!  Also the IO60 and IO61 that are connected just pass on this '1' as it moves through the shift register, thats another one to capture.  If you don't see a pulse on this line on U2 at all, something is wrong.

Just to clarify, the problem you have with two of these displays is that, only the top half is working?  Or do these displays not display any data at all?  I assumed from the first photo, you were just feeding these displays signals, and turning the contrast all the way up/down to test the pixels - because turning the contrast so all the pixels are on (white) shows up dead pixels, and one doesn't need the LCD to display anything for that test.  And that the bottom half wasn't displaying anything because its common driver was funky.  I'm afraid I should have asked about the exact fault sooner.

I still think the "S" (pin 12) on the main connector should connect to IO1 (pin 9) on U1.  I'm not nit-picking your schem here, it doesn't matter if its on the schem, just that, if you don't have continuity between those two on the LCDs, then it means there is no scan start up signal for the entire display, so they wont' display anything.  would be odd if that was the fault, because I don't see how it can become disconnected on two boards, unless there's a weak trace there.


Also, how are you driving these displays?  As in, what controller/board are you using?  The CP/LP/FLM look spot on, I'm just curious

Apologies for disjointed questions, its late, and I tend to just type what I think.

[gkmaia]

You are giving me the opportunity to learn how LCDs work! That is why I am so interested on this troubleshooting exercise.

I will double check your questions tonight and post another update!

[gkmaia]

I think I found something.

My LA ground hook was faulty. In fact we were not seeing the IO120 pulse... those were ghost signals.

Fixed my LA setup and voila... There is not pulse on IO 120, 61 & 60 in both U1 and U2. They are dead quiet. See the "bad" scans bellow.

Also, did the  same hooking setup on my good display. Easy to see now how IO120/61/60 pulse perfectly in 60 clock intervals. Exactly like you said, every 120 CK.

From far is also possible to see how the segment registers align with those blocks of data pulses that are supplied to the segment drivers.

That is pretty cool to see.

Edit:
As I understood the HC74 / 40103 are only there to avoid polarisation.
In regards to what makes the drivers display something in the glass are pins LOAD, CP, D0~3 and IO1~160.

Is there a way to find using logic data analysis which of the 4 drivers is stopping the circuit from being functional?

[Buriedcode]

Ahh now we're getting somewhere!

Good find on the test hooks - I've been there a few times myself.  Lots of noise spikes on the analyzer obviously shows noise, but when its the odd spike - especially in sync with other signals, can throw you right off.

So, no IO60/IO120 pulses, to me, sounds like either these devices are indeed dead, or the lines aren't being selected (there isn't a '1' being sent through the shift register selecting each line at a time).  I'm fairly sure the 'S' (also called, Scan Startup, or First Line Marker, FLM) is a reset pulse for the common/line drivers.  That means this pulse tells those drivers to reset their shift registers so it starts form the top of the display.

You understood correctly

As I understood the HC74 / 40103 are only there to avoid polarisation.
In regards to what makes the drivers display something in the glass are pins LOAD, CP, D0~3 and IO1~160.

Yes, you are correct.  However, the S is also required to drive the display.  Annoyingly, different manufacturers have different names, but generally
 - CP the data load, the clock that loads in D3-D0, so that'll be widthofdisplay/4 clocks per line (in this case 320/4 = 80).
 - LOAD (also called LP, CP2 CL2.. ugh) is the line marker, that is used to indicate the start of a new line - a pulse selects the next line down. 
 - And S/FLM is the reset pulse to start a new frame.  Without this pulse, the display won't work.
 - yes IO160 are the connects to the glass so are required, but not from, the "user" (who provides the control signals).

The HC74 / 40103 use the LOAD (line) clock to produce the M/antipolarisation signal, but another way of producing the M signal is to use the frame/S signal divided by 2.  Some display I have use this, but most use a counter and JK flipflop (40103/74 combo) like this one.   So my point is, the S signal, although it is connected to the 40103, it's main purpose is to start the frame for the display, and so should be connected to U1, pin9.  Without this I dont' think the display will display anything.

I'm not suggesting this is definately the problem, I will do a test later today - this post made me hook up my LM32P07 for testing, even though it seems it has different drivers.  I will disconnect the S signal, and play with the contrast, if the pixels still go all white, but doesn't do that on yours, then that isn't the problem.

So, in the mean time, check that S (pin 12 main connector) is connected to U1, pin9, IO1.  If not, I would add a jumper there.  It can't hurt as its an input pin.  I'll post my results later today.  Good luck!

[gkmaia]

Cool I will try that.

Is it an accurate visual representation of you explanation?

[Buriedcode]

Yup, looks good to me 

I just quickly hooked up my LM32P07 to a test setup.  When the controller (an SED1335) is sending signals, and displaying a cross-hatch pattern, with VEE = -24V, and Vo = -16.5V the contrast is good, raising or lowering Vo causes the display to either go dark, or all "on". 

Now, I disconnected the 'S' signal (almost known as FLM, first line marker).  As expected noise cause the display to flash randomly, so I grounded it to simulate any potential shorts or problems. The screen displayed nothing at all, and only went slightly white when V0 was almost -23V.  So if this isn't connected from the main connector to U1, then it probably won't display anything.

Do your faulty displays have any pixels on at all?

[gkmaia]

No they dont. Top half all pixels are on. Bottom half all pixels are off.


I updated the chart on my previous post. Now I am capturing all common driver pulses. I think now I got a complete scan of what happens to create each column and row. A week ago this LCD was pretty much all in Japanese for me... now it looks like English... I can read it. Thanks mate!!!

Edit: Would be really cool if we could build a circuit to drive the LCD at such low speed that we could see each 4 bit block being written one after the other, row after row.

Edit: Spent almost all my day trying to scope the remaining pins. That is what I found.
If you look at U1/2 scans you will see the faulty display U1-01 is getting the pulse from S as a 75Hz - 0.4% duty. So that is fine.
But... the pulses get all messed up when moving from U1-60 to U1-61, then afterwards the chain breaks and nothing goes to U1-120 then to U2.

I am waiting a few TAB tools to arrive and I could try inverting U2 with U1 and see if it flows then. But I imagine replacing that TAB will be a MISSION!

[Buriedcode]

Right, so, it looks like U1 is the problem, and U2 could be OK, it just isn't getting that line pulse through its shift register.   The extra pulses on U1 IO60 again, look like noise, but the fact that they actually vary in width this time, really does look like its effed    I'm afraid I have no experience with their failure so have no idea why they would fail.

Replacing the TAB IC would indeed be a mission, one can only hope that the "pinout" on the glass is a standard one (I don't see why it wouldn't be, pixels are always arranged the same way, and they're a standard pitch). I have never done it or even seen it done, but I vaguely remember some appnote many years ago regarding the procedure - requires specialist adhesive for connected it to the glass. If you succeed, that would be something one could add to their resume!

One possible simpler test would be, if you're desoldering U1 (not disconnecting from glass, just lifting the pads on the PCB, specifically IO120) then you could connect 'S' to U2 IO1, and see if the bottom half actually works.   Alternatively if the small PCB that they're on has an obvious trace carrying the signal U1 IO120 to U2 IO1, then you could cut that, and botch kynar wire from U1 IO1 to U2 IO1.

I have to say, this was a great piece of detective work.  I was hoping for a straight forward failure, as I'm sure you were.  If you're successful, there my be a small market for these displays as replacements for aging equiment.  A few years ago they would go for about $10 on Ebay.  Now, about $80 US.

Whilst its rather sad I have a soft spot for these displays - to me, they now look quite retro what with their <10 contrast ratio, relatively narrow viewing angle, and 0.33mm pixel pitch.  I've even made custom backlight brackets with RGB LED's so they can be different colours (sad hobby I know..). They have a look you can't really fake with the smaller TFT Modules

[gkmaia]

There you go!

Removed U1, jumped pin 9 of U1 to U2 and I got the top half of the screen at the bottom. U1 was the problem. Basically made U2 be U1.

Quite amazing to see the second driver working as the first one.

[Buriedcode]

Nice!

Also looks like the glass is fine, no dead pixels or "bleed" of the liquid crystal.  Are you planning on attempting to replace U1?  I'm not even sure you can source the driver anymore.

[gkmaia]

I will try to replace it. But will take a while as I will need to do lots of preparation to get the right temperature and pressure.

The driver is pretty much impossible to find. i will need to remove a working one from the another LCD or find one that works in similar fashion then do some adaptations.

Will be a cool project I will keep you posted!

I appreciate a lot your help. I learned heaps!!!

[gkmaia]

Nice!

Also looks like the glass is fine, no dead pixels or "bleed" of the liquid crystal.  Are you planning on attempting to replace U1?  I'm not even sure you can source the driver anymore.

I just got a cheap LM32019 which is 4bit as the LM32. Main difference is the VEE on my original was -24v and on this alternative one is +22v.

What will happen if I reverse bias the VEE bias generator?