Re: Problem with PIC & LCD display

In message <59da1fb5-677b-4c5b-8ba0-4559e7304426@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>, allanhvii@xxxxxxxxx writes

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:
1. Reduce noise causing E-Clock by adding filtering (eg R-C) close to
the LCD module.
2. Reduce noise causing power down / reset by adding caps, filters,
etc. close to the LCD module.
3. Change the software initialization routine to re-initialize the LCD
for 4-bit mode "often".
4. Monitor the busy signal from the LCD to determine when it "thinks"
it has a nibble pair and reset it if out of sync.
5. Run the LCD in 8-bit mode.

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:
1. Wait 150 ms
2. Send 0x3 and wait 150 ms (will stay in 8-bit mode if already there)
3. Send 0x3 and wait 150 ms (will go to 8-bit mode if was in 4-bit
without any garbage nibble)
4. Send 0x3 and wait 250 ms (will go to 8-bit mode even if garbage
nibble was previously received)
5. Send 0x2 and wait 200 ms (should go to 4-bit mode now)
6. Send 0x2, 0x2 (ie byte = 0x22) and wait 200 ms (really should be in
4-bit mode by now - probably excessive!)
7. Send LCD setup sequence (eg 0x2, 0x8 (=0x28), 0x0, 0x8 (=0x08),
etc.)

By the way, in 8-bit mode these issues would be less likely to show up
for a few reasons:
1. The spurious (ESD) writes to the LCD may cause a garbage character,
but a refresh will clean it up.
2. The LCD won't get out of sync the way it does with the nibble
pairs, which is what really messes up 4-bit mode.
3. I suspect 8-bit mode is typically used with the LCD on the
processor's bus, in which case the processor would crash and reset
when seeing this much noise.

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

An update on progress to date:

First of all, there are no conclusions, just observations and suspicions.

There were/are two ways of crashing the display; switching on some other mains powered equipment causing a spike on the supply, or alternatively (and more 'reliably') touching a part of the circuit or enclosure at 0v potential with a screwdriver or meter probe.

I suspect the specific reasons for these two events are different. The mains problem may be improved or cured by better mains filtering. I'm currently more concerned with the touching 0v problem, and now suspect it's due to static. This is exacerbated by what I believe (albeit after limited testing) to be a very sensitive LCD module, if not one which is actually over-sensitive and possible even faulty.

The original display was a Powertip device which uses a Samsung S6A0069X controller. I've now replaced it with an equivalent Batron device which uses a Samsung KS0066UP controller. It's still running in 4-wire mode.

Early indications using the replacement LCD are that the problem has not gone away completely, but the symptoms and severity have been affected. Under provocation, i.e. repeatedly touching a 0v rail whilst attempting to be as statically charged as possible will intermittently cause the first character on the first line of the LCD to corrupt, or much more frequently, the first two characters on the first line will be replaced by the last two characters on the first line, though these are as it happens currently the same as the last two characters on the third line. The rest of the display would be unaffected. As a note to this, only the third and fourth rows have data written to them on the 0.5 second refresh cycle, the first and second rows are written to on initialisation only.

After this corruption has occurred the display remains functional, unlike before when it cleared and remained blank thereafter.

I intend to try it in 8-bit mode but haven't got that far as yet.

I've connected the new LCD with the same equipment wire as the previous, but have no additional decoupling caps fitted to the module itself.

Another change I've made to the set-up is much better (I think) grounding of the chassis and metal panels. The poor arrangement I had before was not the cause of the problem (as altering it proved) but it would not have helped. The ground connection to the aluminium top panel was for convenience taken from the common 0v rail to the four control buttons and shared a return path on the PCB with the PIC and the LCD. There was also a ground loop owing to the fastening of the LCD to the top panel via steel crews. The top panel now has a 0v connection straight to the 0v power input connector, and has no other connection to ground. Similarly, all other metalwork is connected directly to the same point.

Further testing will take place tomorrow and beyond (and I'm half expecting the old problem to show up again...) but preliminary investigations suggest an over-sensitive LCD module to be the major culprit.

--
Steve H
.

Quantcast