LCD Troubles

..........

First time I hooked up an LCD module I wired it wrong and got the controller chips so hot that I burned my fingers, but it still worked afterwards, they're pretty robust little modules, are you sure you didn't burn out an I/O pin on the pic or change some wiring or programming code for the LCD? I'd start from scratch going over both your wiring and the programming to ensure (don't asume anything) that you didn't change something on accident. Does the LCD module share I/O pins with the programmer? The LCD might not work while it's still plugged into the programmer.

It may be pretty obvious?, but revert back to code that worked (presumably you don't overwrite you code as you go?) and see if that still works. If it does, as sounds likely, your latest code changes have 'broken' it!.

I really don't know what to say... I've given up on it for today...

Here's the thread that I have been working on for the last few weeks --> https://www.electro-tech-online.com/threads/a-d-conversion-accuracy.31672/

And here's an attachment of the LCD in action --> https://www.electro-tech-online.com/attachments/dcp_5404-jpg.13961/


That is what is confusing... I did not change anything hardware wise, and only added a couple of bsf instructions, and initialized TMR1 before it stopped working. I removed everything that I added and it still wouldn't work again.

I tried another known program that I had (but had to wire up a dev board to the LCD module -- long story short, I ran out of program space on the 16f873 and moved up to the 16f877, so I know the 873 program worked).

I've even started from scratch and directly cut and pasted Nigels tut 3 (a couple of the versions) and modified it slightly for the 16f87x. Still nothing.

So, basically, I've tried two different programs that I had that were working... and 2 from Nigels site... with two different LCD modules... on two different dev boards.

The LCD does not share any pins with the programmer and the LCD worked fine for over a month with the programmer (in debug mode) -- that's the frustrating part!

It just seems like the LCD is not initializing. If I try to use Nigels tut 3 that uses the busy flag check, the routine never exits (the busy flag remains set).

Nigel Goodwin said:

It may be pretty obvious?, but revert back to code that worked (presumably you don't overwrite you code as you go?) and see if that still works. If it does, as sounds likely, your latest code changes have 'broken' it!.

Click to expand...

Yeah, I wish it was that easy!

I do make backups as I go, but not generally on each small change -- usually on significant changes. And, as I said, the change was so minute and was removed immediately after. This was a flag set (bsf flags, 5) and 5 bsf instructions to set 5 pins high on another PORT... and I initialized and wrote a value to TMR1 (just above the 6 bsf instructions) -- all of which were removed.

Is there a way to setup an "auto backup" with MPLAB?

Strange part is, I can't get any of your tutorial examples to work either.

I just added an LED to a PORT pin and flashed it off and on with 1/2 second durations just to check everything else out (oscillator, etc.), but as I said, my original program still runs fine in the background... it is not hanging or crashing. I can still open all doors (it's a safe lock) and add users, delete users... everything... just have to do it blind.

You're almost certainly doing something silly

It could be either software or hardware, which makes it tricky to find - however, if you can't get my tutorial code to work you have a hardware problem, as the code (and the hardware as described) is fully tried and tested. Obviously, if you modify the code, or the hardware, you could easily break the tutorials.

Nigel Goodwin said:

You're almost certainly doing something silly

Click to expand...

Oh, that'll be a given!

I have some 8 bit code that I had working originally (as per the image above), so I may give that a go after dinner. (I changed it to 4 bit code about 2 weeks back when I added an EEPROM and RTC.)

It is a valuable couple of lessons though...

1) I have to figure out a good method of backing up code for just this reason

2) I have to create a few known good test programs and keep them handy

Kyle-s4h said:

1) I have to figure out a good method of backing up code for just this reason

Click to expand...

I tend to save every appeciable change, so startoff 'filename', then 'filename01', then 'filename02' etc.

One don't need a PIC to tell if the LCD is dead, if it is using a form of controller like the common HD44780.

Remove the LCD from circuit, connect the contrast pin to 0V and then apply power to the LCD, there "should be" a row of black blocks displayed on the first row. All my LCDs does this.

Kyle-s4h said:

Oh, that'll be a given!

I have some 8 bit code that I had working originally (as per the image above), so I may give that a go after dinner. (I changed it to 4 bit code about 2 weeks back when I added an EEPROM and RTC.)

It is a valuable couple of lessons though...

1) I have to figure out a good method of backing up code for just this reason

2) I have to create a few known good test programs and keep them handy

Click to expand...

hi,
Download 'Karens Replicator' its a freebie.
With it you can have a timed or manual backup from any folders. I backup folders from the C:\ drive to the same named folders on the D:\ drive.

A word to the wise, when you backup you will overwrite the earlier files in the folders. So as you get a 'good/tested' assembly, rename the program, a simple progname1 to progname2.. etc is all you need to do.

If you have a CD writer on your PC, buy some re-writable CD's and backup to a CD.

This is the best way, if you ever get a hard drive failure, at least you havn't lost months of work

Can you post a 'full' lcd program so that we can see what you are doing?

Rather than over-write an existing archived file with the new current file, does the above software allow renaming an archived file of the same name, to one with a current date/time stamp post-fix in the filename?

This would preserve all the changes made and still allow user to fall back to older copies if need arises.

Kyle here's a link to some 4bit PIC routines.
**broken link removed**

Thank you all for the tips!

I didn't get much time at all to work on it yesterday, but I did manage to get a breadboard working with Nigel's 4-bit code. As Nigel said, "you're probably doing something silly" -- well, I was. (Sort of!)

The code would not work on my test breadboard as I had forgotten that I did blow an I/O pin on the 16f873 a while back and tried to put a control line from the LCD on that pin -- duh! (I have been using the chip for development and that pin was reserved for a door output, so I hadn't been using it.) Unfortunately, it's still a no-go on my original project -- strange.

Great, so at least I can now test my LCD modules -- all of which are working. This, at least, narrows it down to hardware / software on my end. The hardware I've double and triple checked, so I must have put something else in the code that I am forgetting and have been unable to find.

A week or so ago, I ran out of the 4K codespace on the 16f873, so I bumped the chip up to a 16f877. When I did this, I started bringing the code over a little at a time as I was trying to organize my code at the same time by creating separate files for each "module" that I was working on. I brought the LCD routines over first, then the I2C routines and had the clock displaying. I then slowly brought all the other code over to the 877 as I organized it. This makes it a little more difficult to backup, and hence why I did not have one. I use to back up quite often when I was working with a single file, but with multiple files it is a PITA! Oh well, like I said, lesson learned!

My point to the above was that I should have some time to work on it today and will probably do the same as I did when bringing the code over from the 873... I'll start with the LCD routines and go from there.

eblc1388 said:

One don't need a PIC to tell if the LCD is dead, if it is using a form of controller like the common HD44780.

Remove the LCD from circuit, connect the contrast pin to 0V and then apply power to the LCD, there "should be" a row of black blocks displayed on the first row. All my LCDs does this.

Click to expand...

Thanks for that -- I actually did do that to start with, but didn't know if the row of squares indicated the LCD was fully operational or not. I'd be curious to see the results of a non-functioning LCD with this test. I mean, if one data line wasn't working, for example, would you still get the squares?

Either way, it's a good tip to know! Thanks!

What I have now is proto board with a 16f88 and a 16 pin SIL socket for the LCD... all it does is runs Nigel's 4-bit code and displays "Hello" (line 1) and "Ready..." (line2). Hit the reset button and it does it again. What the heck, eh? Now I have a basic LCD tester for about $8.

Kyle-s4h said:

Thanks for that -- I actually did do that to start with, but didn't know if the row of squares indicated the LCD was fully operational or not. I'd be curious to see the results of a non-functioning LCD with this test. I mean, if one data line wasn't working, for example, would you still get the squares?

Click to expand...

All it means is that's it's not completely dead, nothing else - you get the black squares (just on the top line) when you turn the contrast up, if the LCD hasn't been initialised.