Problem with PIC & LCD display

No. The "busy" ONLY works AFTER the display is initialized. This is a very, very common mistake.

I know you have checked your initialization timings - but I still feel this could be the problem(?). Just to be sure, I would burn 2 seconds between each init write to the LCD. That will tell you for certain whether it's software-related init problem. Then, you can go back and figure out what timing spec if off and fix it.

It "sounds" to me like the LCD is being written to before it is properly reset. If so, this can cause all sorts of weird behavior.

Can you post your LCD startup code for us?

-mpm

Thank you. Many LCD controllers that default into the byte mode and are difficult or unreliable to set into the nibble mode.

In message , snipped-for-privacy@gmail.com writes

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, "As I've explained in previous posts, the LCD is written to twice a second normally. Slowing this down significantly to refresh every 3 seconds showed that the display does not blank immediately when the

This is a VERY significant clue to the problem. What it tells me is that the LCD is probably fine, and the event causing the LCD to blank is external, and most likely, in the code.

To me, having read all of the above, it does seem that you've ruled out power glitches, etc... (I know, soon as I say that, some power rail problem will rear its ugly head..) :)

Here's what I would do. SLOW DOWN THE LCD TO A CRAWL. Literally. On your LCD initilization routine, add some debugging code: My thoughts:

Init the display (in 4-bit mode). Take your time doing this; there's no rush. The LCD does not care how long it takes, it just wants all of the minimum times are met. Code enough delay (at least 2 seconds per command) so LCD Timing Init is absoultely ruled out.

Then, write a test message to the screen: "LCD RESET" Then, loop a couple more seconds in code, and only then, go on to the rest of your program.

Then, while testing, if you EVER see this message again, you know without a doubt that the LCD init code has run again. And that means the problem is NOT with the LCD itself, but rather is in response to some other event affecting your program flow. Perhaps a PIC reset, but not necessarily so.

Perhaps you have already tried my suggestions until you are blue in the face, and if so, ignore the above. However, I have to tell you, from here, this problem smacks of improper init timing, and subsequent external event that is somehow re-init the LCD.

The LCD itself has to be powered up for some minimum time before you can start talking to it. (I presume you know that.)

At any rate, good luck! Sounds like an interesting challenge!!

-mpm

On a sunny day (Wed, 7 May 2008 17:45:02 +0100) it happened Steve H wrote in :

Good sounds like that was the reason.

Do not bother.

Long time ago (12 years or so?) I did drive such a text LCD via I2C bus (3 wire). The trick is to use a PCF8574 I/O expander to drive the LCD lines. That chip has 8 programmable I/O, and I2C input. Worked nice over several meters of wire.

The soft is more involved, may have some old MCS BASIC program if somebody needs it.

Good.