Propeller and HD44780 16x2 LCD Reset Problem
stevovee
Posts: 18
I'm using a parallax propeller with an HD44780 16x2 LCD. The LCD works great with one exception. If I hit the reset button which resets the processor the screen gets garbled. When I do this the screen does not lose power and it shouldn't. I know these screens have an automatic hardware setup and this seems to work. If i completely unplug the board It will work. I've been researching ways to reset the screen in my code so that if I hit the reset button I no longer have this issue without any kind of hardware redesign.
Right now i'm using this object http://obex.parallax.com/object/338
once i get further into my code i have a loop that runs and the screen prints fine then but I'd like it to say some things right after reset that just come out garbled.
Does anyone have any experience with this and/or know how I can reset without the garbled text.
Right now i'm using this object http://obex.parallax.com/object/338
once i get further into my code i have a loop that runs and the screen prints fine then but I'd like it to say some things right after reset that just come out garbled.
Does anyone have any experience with this and/or know how I can reset without the garbled text.
Comments
I'm having a similar/same problem with my HD44780 LCD (sound of head banging on the bench).
I wish I coupld provide a simple answer to this problem. I've been hammering on this for a some hours last night and today. But maybe you can benefit from my findings so-far (hence the long post)...
As far as I know, if all the connections and power busses are correct, and you're using series protection resisters between the 5V LCD and the 3.3V Propeller pins, then the on power up all "generic" HD44780 LCD's will be in factory default 8-bit data mode and must be programmed (initialized) by the driver first to work in 4-bit mode. You do not need all eight (db0-db7) LCD pins connected to initialize to 4-bit mode (db4-db7 connected).
I'm using a 5V (only) 4x20 P/N YB2004A HD44780 compatible LCD with blue background and white characters in 4-bit mode. Many have used this particular LCD module with success.
All the LCD data I/O and control lines are connected to the 3.3V Propeller via 4.7K resistors for protection. All my connections to/from the LCD are less than around 3 inches and connected directly to the prop pins on my tried and true home-brew DIP Propeller dev board.
I first tried the "jm_lcd4_ez" V1.5 from LCD driver from Obex:
http://obex.parallax.com/object/313
The first time I connected the brand-new out-of-the box LCD and ran the jm_lcd4_ez driver object it worked fine. Just as expected from what I can see in the driver demo object when properly configured for my 4x20 LCD connected to the Prop-I.
The contrast is set properly on my LCD from the first succesful run of the jm_lcd4_ez object. My LCD likes 0.7V on the contrast pin, which from my experience is correct. At the moment I'm setting the contrast from the wiper of a small Bournes PCB mount 10K multi-turn pot with the pot's end-leads connected between 5V and GND. 5V is connected to the CW rotation wiper end.
Tip: If you don't want to use a pot to set the contrast, try putting a signal diode like a 1N914/1N4148 diode with cathode to ground in series with a 4.7K or 10K resistor to 5V, then connect the diode cathode to the LCD's contrast pin. This should set your contrast pretty-much correct without having to use a pot or a fixed divider. But before doing this you may want to verify your LCD contrast is OK with around 0.7V on the contrast pin with a pot first.
With the backlight on the 5V bus is reading about 4.9V, so the backlight isn't overloading the 5V power bus. The backlight is drawing around 110mA which is as expected for this 4x20 LCD. My 5V bus is regulated via a venerable 7805 regulator fed with 8V.
Back to the demo object test:
Next, with the jm_lcd4_ez driver working, and without making any changes to the driver example code, I reloaded the previously working jm_lcd4_ez object code into the Prop RAM.
Now the LCD doesn't work any more, no matter what I do...
Any type of power on/off reset and reload of the object doesn't work. Now the LCD just sits with the top-most line and third line from the top all pixels on and the other two lines blank. I think this may be the correct initial power on display for the 4x20 LCD. I remember with 16x2 HD44780 LCDs that power on reset with no data coming in results typically in the top line being all pixels on and the second line being blank.
As I remember, these generic HD44780 LCD's don't have any hardware reset pin. The LCD's are reset to factory defaults upon power up with no non-volitile storage on the LCD. You have to properly re-initialize the LCD for data-pins used (4 or 8) etc. in software upon first power-up every time. If this is indeed true in my case, then I shouldn't be seeing this problem unless there is a hardware interconnect problem.
I probed all the data and control pins with a scope (100MHz Rigol DS1102E) and they are toggling just fine. No cross-talk that may cause problems - at least that I can see.
Nothing I do now will work with the LCD.
I tried the "LCD Driver for HD44780/KS0066" from Obex using the "LCD_20x4_Test.spin" demo object:
http://obex.parallax.com/object/337
Nothing, same as the jm_lcd4_ez object now, even with all permutations of reseting the propeller and LCD separately.
Next I added a three second delay to both of the objects mentioned above right after power up and before the LCD is initialized. This was just to make sure everything settles down before communication with the LCD starts.
Nothing, same as before.
I reinstalled the LCD Ohming-out all the connections to make sure they're OK.
Nothing, same as before.
Unfortunatly, I don't have another LCD to try.
My gut feeling is that there is some form of inconnection issue or cross-talk between leads connected to the LCD.
Anyway, here's my planned trouble-shooting path for now:
1. For a third time, reconnect and recheck the LCD/Prop interconnections. Maybe make the leads shorter or reduce the 4.7K protection resistors to something like 2.2K (in desperation).
2. Order a couple/few more LCD's for comparison.
3. Try the LCD with an ATmega328 Arduino driver Yeah I know... Aurdino :-(
4. Connect the logic analyzer to the LCD pins and sniff out what's happening.
5. Read up a lot more and possibly write my own bare-bones test driver.
Here's a couple/few of links that may help:
This thread is about someone having similar problems with an mbed board:
This page has a lot of info about interfacing HD44780 LCD's:
http://www.ekenrooi.net/lcd/lcd.shtml
The "4-bit Parallel LCD driver" by Chris Gadd in Obex is very well documented, worth a read IMO. Unfortunately for me I'm trying to use a 4x20 LCD, this object is for 16x2 only. I'm not sure if this matters for a simple test though. I may give it a try:
http://obex.parallax.com/object/87
I recommend you try the following:
* Recheck all your LCD connections. Keep them short. Try to separate the pins for the control lines to reduce cross-talk (the four data connections typically all need to be contiguous). I do not recommend trying to drive the LCD via a "plug breadboard". Make a direct connection cable with series resistors "mash-up" cable instead. An old floppy drive connector/cable cut down (short) with soldered series 1/4 or 1/8 Watt resistors can be used for this in a pinch. Apply some hot glue to the resistors to keep them in parallel, at least for the four LCD data pins, if you are separating the I/O control pins.
* Be SURE to use series protection resistors between the 5V LCD and the 3.3V Propeller to prevent damaging the Propeller during power-up and LCD initializatoin or LCD read.
* Recheck how you are setting the LCD pins in the driver object. Check the pins with a logic analyzer if you have one (I use the Open Bench Logic Sniffer).
* Try putting a waitcnt delay of several seconds in your LCD demo object before the LCD initialization occurs to allow things to settle down before the LCD driver starts communicating with the LCD. This example will introduce a wait of 3 seconds:
waitcnt(clkfreq * 3 + cnt)
* Try the LCD without the backlight on. Maybe the backlight is overloading your 5V bus. The backlights take a lot of current. If you do use the backlight, make sure the 5V bus voltage is within tolerance.
* Try the jm_lcd4_ez LCD driver. It worked well for me ONCE. But at least I can report it did actually work at one point.
Is this perhaps that when reset the Prop IO lines all float and your RW line to the display waves around causing random writes to the display? Try a pull-up line to force it to read mode under reset.
Not all HD44780 clones behave the same but in general if there is one rule, it is that you MUST follow the initialisation routine, as shown in the datasheet EXACTLY. Not the examples you found on a forum, not some sample code from a display manufacturer and not some example code found on the 'net. Only the datasheet will do.
I've yet to come across an LCD issue which, assuming the electrical side is right, cannot be fixed by correct initialisation.
LCD_16x2_4Bit - modified.spin
-I also changed the I/O lines so be sure to reset them to your pins
Not on the display you have in front of you but one day having it in there will save you hours of debugging.
Excellent work! I have never used a Parallel interface LCD without checking the busy flag before each transaction on the bus. That is how it was intended to be used and often I see time delays really hurting performance in something like this.
Anyway, I had been working with a NewHaven 4x20 OLED display which uses a "HD44780 compatible" driver IC back in August. I too had been experiencing problems from a warm boot such as when sending a new flash file to the Prop the display would come up with garbage. I worked with the applications engineer from NewHaven trying to resolve and never did get it to completly work correctly. It would work maybe 75% of the time. For the other times it wouldn't I made a WatchDog timer. I noticed that when the display would hang up it would never return correctly from initialization so here is what I did and it works whenever the display hangs up with garbage on it:
Then here is the WatchDog:
I tried modifying the driver code to follow EXACTLY as they mentioned in the data sheets for initialization but still had problems. I worked on this for several days and still couldn't figure it out.
When I get some time I'll look at your driver (I see it's written in assembly) and see if I can modify it for a 4x20 and see if it solves this problem.
And yes I too am using it in the 4-bit mode.
I can't quite tell if you're saying that the routine you shows works OK or not.
I can see that it doesn't follow the routine published in the datasheet fig 24.
No it doesn't work properly. I have not compared it to the actual HD44780 recommendation but only to the recommendation published by NewHaven Display. I'll need to compare it to the HD44780 datasheet and see if I can fix it.
My kludge "WatchDog" method is a band-aid in the mean time....
I updated my LCD routines to include one written entirely in SPIN, plus made some other changes to the handler routines, and in deference to Brian am using the initialization method specified by the datasheet. I realized that my PASM routine wasn't allowing enough time for the commands to go through, which is what the business with the flag was about, but that's fixed now.
@stevovee - I goofed something else in the modified 4x16 driver. In the initialization method: outa[DB7..DB4] := 0010 should of course be %0010.
http://forum.arduino.cc/index.php?topic=91659.msg3890589#msg3890589
See attachment page 28.
Greetings from Buenos Aires, Argentina !
Welcome to the forums! Most of the members here do not have the book you reference. We can not see the code you refer to. We normally use official Parallax book.
Is this LCD you refer to a parallel or serial LCD?
Attach pictures of your wiring to the LCD and also attach the code that you are running.
Where did you get your LCD from?