The problem seems to be with the PIC and not the display, Ive had similar problems with this series PIC, shorting the MLCR pin to Vcc at the PIC pins cured it, eventually I changed the chip for the PIC18 series, altered the MLCR circuit and had no more trouble.
I'm having the same type of problem with a new design using a 2 line x
16 Optrex display with an Atmel Arm 7 micro in the 4-bit mode. I tried swapping to a Hantronix display with little or no improvement.If I create a high voltage arc near (within an inch or so) the LCD (without even touching the board), the display goes into a lockup state. I've changed the software to attempt a software reset of the LCD, but nothing seems to shake it loose except a power cycle. (The LCD has no reset line.) Also, the processor is still running, evidenced by the debug data it pumps out as well as a few other indicators. The LCD unit is mounted 1/4 " from the main PC board using standoffs and a connector; there is no ribbon cable.
I generate the arc using a lighter (without the tank), which is a piezo electric spark. (A long handled grill lighter.) I started this because the board had difficulty in conformance testing with the ESD test.
Have you made any progress on your problem? Maybe we can share our results.
I tried stopping the software updates to the LCD (per your tests), and found the same results:
- Run the software to setup the LCD, etc.
- Tell the software to stop writing to the LCD
- Generate the ESD
- At this point, the LCD looks fine
- Tell the software to reinitialize the LCD and start updating it again.
- At this point, the LCD appears scrambled or blank.
On another note, I found that my ESD generator (aka grill lighter) only generates enough ESD noise if the arc passes around a wire in a loop. Simply using the lighter as it came from the store will not trigger the failure.
Looks like I'll be working on this all weekend. I'll let you know what I find.
Are you certain your micro hasn't restarted. Are you sure your software LCD reset routine works?. Are you driving the lines correctly from an analoge point of view?
.
is
)ll
g .I'm positive the micro has not restarted. Further, all other systems appear to survive the static without issue. The LCD reset routine works, and it is able to recover the LCD in some cases (see below). There is some ringing on the lines, and I've considered adding terminators. The traces are very short, and the connector (PCB to PCB) is only 0.25 inches. But, the LCD will fail even when the micro is not updating the LCD and all of the LCD signals are low at that point.
New information: I'm now stopping the microprocessor updates to the LCD before "killing" it to make the testing simpler and more consistent.
Data Point 1:
- If I "kill" the LCD once, the microprocessor LCD reset software usually cannot recover it (no matter how many times it tries.)
- If I "kill" the LCD again, the microprocessor LCD reset software can usually recover the LCD. It's as if whatever gets screwed up gets un-screwed up when I hit it again, sometimes.
Data Point 2: I've noticed that writing to the LCD controller when it is going through reset (power up) is a very bad thing. It messes up the LCD and it cannot be recovered, in much the same way as the static discharge. Maybe the LCD is getting some type of partial reset from the discharge? I'm not reading the "busy" signal from the LCD, which would indicate "not ready" if the LCD were going through reset.
Data Point 3: I've tried disconnecting some of the signals between my board and the LCD after the processor's initialization routine runs and the micro LCD updates are stopped. I'm still testing in this area, but the theory is that perhaps pulling some signals high during the static discharge rather than low (as they are now) would make a difference. So far, no improvement.
Data Point 4: To try to isolate (somewhat) the problem to either the LCD or my PCB, I used a ribbon cable between the two boards. The LCD will still have the same problems no matter if I discharge near it or near the cable, but it appears to be most repeatable / noticeable near the LCD. I also tried discharging near particular signals in the cable (by splitting up the ribbon), but that didn't seem to make any difference, either.
Data Point 5: I changed the drive voltage for the control signals from 3.3V to 5V. This had no effect, as would be expected since these signals are all at 0V when the discharge takes place.
I'll be swapping the LCD unit with one in another system (where no failures are seen) to see if I can pin it to the LCD vs my PCB.
Thanks, Allan
On a sunny day (Fri, 2 May 2008 15:17:48 -0700 (PDT)) it happened snipped-for-privacy@gmail.com wrote in :
If you have a spare I/O pin, then you could perhaps power cycle the LCD from the PIC. It is a kludge... but if it works...
Is it possible that the PIC watchdog is running?
In message , snipped-for-privacy@none.com writes
No, that's definitely off. Caught me out once in my very early 16F84 programming...
The program worked perfectly on a breadboarded layout, the problem only showing up when assembled.
-- Steve H
One thing I noticed when when looking at my 4 line LCD: Did you perhaps connect the LCD ground plane so it is connected to a metal case? And is the PIC board connected to that same case? Could be interesting ground loops. What if the LCD module floats, is the error still there then?
The problem still occurs when the LCD module is unfastened from its fixings, i.e. 'floating'.
On the subject of the LCD ground plane, as originally constructed, the module is fastened to the aluminium top panel using four steel bolts. There was an additional ground connection to the panel from the common connection to the four switches, so that would have created a ground loop, albeit with an insignificant current flowing.
One or other of these connections will be taken away. Is there a reason to connect the LCD ground plane to 0v via the through-plated fixing holes, or is it of no consequence?
-- Steve H
The ground plane is connected to the ground pin on the connector edge. For RF it is perhaps better to make an extra connection from the screw in the front panel that hold the LCD to the ground pin. This will ensure 100 % contact, as in my case the solder mask may prevent contact with the screws. It all depends, if you ground the other boards too on the case, and the distances, how much current could flow etc..
The other issue, is the case grounded, or to put it better: connected to mains earth? Else it may carry some weird voltages, and then if you touch it you create a capacitive current path.
Did you try an other LCD module already?
The case is plastic with an aluminium top panel and a thick aluminium base plate inside the case. The top panel is connected to 0v as described above, the base plate is connected to 0v at a different point. There's no other physical connection between the two to cause any ground loop.
The unit will be powered from either a 12v switch mode power supply or a
12v lead-acid battery. There's no connection to mains earth using the SMPS.Have ordered one, expect it mid next week.
-- Steve H
Do you have traces running under the unit?
-- "I\'d rather have a bottle in front of me than a frontal lobotomy" "Daily Thought: SOME PEOPLE ARE LIKE SLINKIES. NOT REALLY GOOD FOR ANYTHING BUT THEY BRING A SMILE TO YOUR FACE WHEN PUSHED DOWN THE STAIRS. http://webpages.charter.net/jamie_5"
Steve: I've been having similar problems with my new design.
I swapped out the LCD which was getting scrambled with an old unit of a different model. The old unit works fine. Just to be sure, I put the original (newer) model back in again, and it still fails. I'll be ordering more LCD's!
I think the new (failing) units are using the NT3881 controller chip, which is HD44780 "compatible", whereas the old (working) unit is assembled with the real HD44780 IC. You may want to check which IC is used on your unit. I suspect the circuitry (reset or otherwise) on the NT3881 is not working properly. To be fair, I can't be sure what IC is being used on the new units because it is bonded & epoxied onto the PCB, but the resistors, etc. on both boards match the NT3881 specs, and the Hantronix model calls out this IC (or equivalent).
Does your board have components near IC1 such as R6=91k; R1,R2,R4,R5 =
2.2k; R3 = 0? You may want to order a few LCD's with different controllers.Allan
"Steve H" schreef in bericht news: snipped-for-privacy@spho.demon.co.uk...
Reading your descriptions I'm almost sure the problem is in the power grid, most likely the ground side. You may find some clues by removing the ground and power wires between processor board and display and replace them by (relatively) thick, short wires directly from the regulator on the processor board to the display. You may add some (as short as possible) wires from the regulator to the processor as well.
petrus bitbyter
Oops. I take it all back. The old LCD fails as well, but not always. Now I'm thinking the problem has to do with the power up or init sequence. Sorry for the mis-information.
Allan
Steve: I finally made some actual progress. Please let me know if this helps.
First, don't expect to have a system immune to all noise. The noise will effect the signals to the LCD, and it will cause problems for the LCD unit. So the questions are (1) how to best reduce the noise and (2) how to handle the LCD errors.
Background (As we all know...): In 4-bit mode, the LCD is expecting 8 bit commands as pairs of 4 bits. At reset, the LCD is in 8-bit mode until you send it a command to put it in 4-bit mode. This command is actually in 8-bit mode itself, so you only need to send 1 nibble since the other half of the bus is not connected. Once this command is accepted, all the commands which follow must be in pairs of nibbles. If the LCD ever gets out-of-sync with the software sending the nibble pairs, we're in trouble! This explains why the LCD often looks okay until new data is sent to it; it's out of sync, or maybe even back into 8-bit mode.
If any noise is interpreted by the LCD as either E-Clock, power down, or reset, the module will get confused because it will be expecting a nibble, not a nibble pair. At this point, the LCD must be reinitialized for 4-bit mode (again).
Solution Options:
I'd consider #3 mandatory, and the others optional.
I've started using the following sequence since the sequence specified in my LCD's manual couldn't recover the module after ESD. This must be sent every so often to the LCD in case it gets locked up, but can be sent to a working LCD as well. For testing, I've used very long time delays (shown here) and probably an overly complicated sequence. I'm going to try to shorten the times and the sequence tomorrow, but this works:
By the way, in 8-bit mode these issues would be less likely to show up for a few reasons:
Just one more note. The spec for the LCD I'm using indicates the unused data pins DB0-DB3 should be pulled low, but other related specs indicated otherwise. I'm experimenting with pulling them such that 8- bit command to go to 4-bit mode will also setup my LCD for 2-line operation, to help avoid the flicker caused by this reset sequence.
Allan Vaitses
No, the display module is set away from any other PCB.
-- Steve H
In message , snipped-for-privacy@gmail.com writes
This is very interesting. It provides a seemingly highly plausible explanation for why the display crashes only on a write operation.
I wonder how common it is for 4-wire mode to be used with these display modules rather than 8-wire. If it does turn out to be the aggravating factor causing such problems, it could explain - if 8-wire is the norm - why I seem to be in a tiny minority in having difficulties.
I used 4-wire because (a) it ties up fewer pins on the PIC, (b) it made the PCB layout a little easier and (c) because it's programmed using a Basic compiler, there's no additional effort required to cater for the
4-wire write operation. That, and the fact that there's no theoretical reason to use the display in this mode, it's designed for it after all.As it happens, to convert from 4-wire to 8-wire as it stands will be straightforward. It's certainly now top of the to-do list.
The display I'm using is a Powertip device. I don't know what chip it uses as it can't be determined from looking at the module
I'll let you know what the results are - won't be until Tuesday or Wednesday.
-- Steve H
On a sunny day (Sun, 4 May 2008 12:45:17 +0100) it happened Steve H wrote in :
Well, I use 4 bit mode, and I think most applications do, for exactly the reasons you state below. And I never had a problem, already used 4 wire mode as much as 18 years ago!
There is something on the net about a different initialisation for some displays, for mine the normal PIC example from Microchip worked (that I probably modified...). The vendor should provide you with that info, or at least mention the chip set, so you can look up that data sheet.
I think my 4 line display uses the KS0066 from Samsung.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.