Propeller and HD44780 16x2 LCD Reset Problem

stevoveestevovee 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

o
nce 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

  • 17 Comments sorted by Date Added Votes
  • ChrisGaddChrisGadd Posts: 257
    edited October 2013 Vote Up0Vote Down
    I'm guessing that you're running it in 4-bit mode? The LCD starts in 8-bit mode at power up, then is placed into 4-bit mode by instructions. The display then glitches if the same code is run a second time while the display is still in 4-bit mode. Page 212 of the HD44780 datasheet describes how to initialize by instructions and time delays. The LCD driver in my sig also re-initializes after resets, but does so using the busy flag.
  • DroneDrone Posts: 433
    edited October 2013 Vote Up0Vote Down
    Hi stevovee,

    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.
  • Brian FairchildBrian Fairchild Posts: 487
    edited October 2013 Vote Up0Vote Down
    stevovee wrote: »
    If I hit the reset button which resets the processor the screen gets garbled.

    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.
  • Brian FairchildBrian Fairchild Posts: 487
    edited October 2013 Vote Up0Vote Down
    Drone wrote: »
    I'm having a similar/same problem with my HD44780 LCD (sound of head banging on the bench).

    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.
  • ChrisGaddChrisGadd Posts: 257
    edited October 2013 Vote Up0Vote Down
    I modified the LCD16x2_4bit driver to properly check the busy flag and got it working reliably on my setup. Curiously, the initialization routine specified by the datasheet doesn't seem to be necessary, but it's still included--commented out--if you're still having problems.
    LCD_16x2_4Bit - modified.spin

    -I also changed the I/O lines so be sure to reset them to your pins
  • Brian FairchildBrian Fairchild Posts: 487
    edited October 2013 Vote Up0Vote Down
    ChrisGadd wrote: »
    Curiously, the initialization routine specified by the datasheet doesn't seem to be necessary...

    Not on the display you have in front of you but one day having it in there will save you hours of debugging.
  • Chris SavageChris Savage Parallax Engineering Posts: 14,406
    edited October 2013 Vote Up0Vote Down
    ChrisGadd wrote: »
    I modified the LCD16x2_4bit driver to properly check the busy flag and got it working reliably on my setup. Curiously, the initialization routine specified by the datasheet doesn't seem to be necessary, but it's still included--commented out--if you're still having problems.
    LCD_16x2_4Bit - modified.spin

    -I also changed the I/O lines so be sure to reset them to your pins

    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.
    Chris Savage | Engineering Tech | Main Office: (916) 624-8333 | Direct to Tech Support: (888) 997-8267 | Website | Twitter | Google+
  • JonnyMacJonnyMac Posts: 6,092
    edited October 2013 Vote Up0Vote Down
    I've done it both ways. If you have the spare IO pin, using the busy flag is the way to go.
    Jon McPhalen
    Hollywood, CA
    It's Jon or JonnyMac -- please do not call me Jonny.
  • Don MDon M Posts: 1,572
    edited October 2013 Vote Up0Vote Down
    Don't know how I missed this thread yesterday....

    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:
    WatchDogCog := cognew(WatchDog, @stack)               ' Launch WatchDog for display startup   
       
    oled.initx(EPIN, RW, RS, DB4, COLS, LINES)            ' Start display
    
    cogstop(WatchDogCog)                                  ' If display started ok then stop WatchDog
    

    Then here is the WatchDog:
    pub WatchDog | t
    
      t := cnt - 1776                                       ' sync with system counter
        repeat 750                                          ' Set delay for 750 mS
          waitcnt(t += MS_001)
    
      term.str(string("Display failed startup...", 13))
      pause(500)      
    
      reboot
    

    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.
  • Don MDon M Posts: 1,572
    edited October 2013 Vote Up0Vote Down
    Here's the initialization method from the driver I used:
    pub Initialize                  ' Modified 8/3/2013 
    
      outa[e]  := 0                 ' Clear pins
      outa[rw] := 0
      outa[rs] := 0
      outa[db7..db4] := %0000
       
      dira[e]  := 1                 ' Make pins outputs        
      dira[rw] := 1       
      dira[rs] := 1       
      dira[db7..db4] := %1111 
    
      BlipE
    
      outa[db7..db4] := $02         ' Send high nibble of 0x20                               
      BlipE
    
      Cmd($08)                      ' Display OFF command
    
      Cmd($28)                      ' Set to 4 bit mode
    
      Cmd($10)                      ' Cursor / display shift command
    
      Cmd($06)                      ' Set to data entry mode
    
      Cmd($01)                      ' Clear display
    
      Cmd($02)                      ' Set cursor to Home
    
      Cmd($80)                      ' Same as set cursor to Home?
    
      Cmd($0C)                      ' Display ON command
    
    pub Finalize
    
    '' Makes OLED buss pins inputs
    '' -- works only if OLED has been previously defined
    
      if inuse
        dira[e] := 0      
        dira[rw] := 0      
        dira[rs] := 0      
        dira[db7..db4] := %0000 
        inuse := false
    
    pub Cmd(c)                      ' Modified 8/3/2013 
    
    '' Write command byte to OLED
    
      'Wait_Busy                     ' Wait for OLED to be ready
      outa[rs] := 0                 ' Set Register Select to 0 for Command mode
      dira[db7..db4] := %1111       ' set buss to outputs
      outa[rw] := 0                 ' Set Read / Write to 0 for Write mode
    
      outa[db7..db4] := (c & $F0) >> 4  ' Output high nibble
      BlipE
      outa[db7..db4] := c & $0F     ' Output low nibble
      BlipE
    
      Wait_Busy                     ' Wait for OLED to be ready   
    
    pub Out(c)                      ' Modified 8/3/2013
    
    '' Print character byte to OLED
    
      'Wait_Busy                     ' Wait for OLED to be ready
      outa[rs] := 1                 ' Set Register Select to 1 for Data mode
      dira[db7..db4] := %1111       ' Set buss to be outputs
      outa[rw] := 0                 ' Set Read / Write to 0 for Write mode
    
      outa[db7..db4] := (c & $F0) >> 4  ' Output high nibble
      BlipE
      outa[db7..db4] := c & $0F     ' Output low nibble
      BlipE
    
      Wait_Busy                     ' Wait for OLED to be ready   
    
    pub Wait_Busy                   ' Modified 8/3/2013
    
    '' Reads busy flag and cursor address
    '' -- returns cursor address when busy flag has cleared
    
      dira[db7..db4] := %0000       ' make buss pins inputs
      outa[rs] := 0                 ' command mode
      outa[rw] := 1                 ' read
    
      repeat
        outa[e] := 1                ' request bf + high nib
        waitcnt((50 * US_001) + cnt)' let buss settle
        addr := ina[db7..db4] << 4  ' bf + high nib of address
        outa[e] := 0                ' finish nib read
        waitcnt((50 * US_001) + cnt) 
        outa[e] := 1                ' request low nibble
        waitcnt((50 * US_001) + cnt)
        addr |= ina[db7..db4]       ' low nib of address
        outa[e] := 0
      while (addr & %1000_0000)     ' checking busy flag
    
      'return (addr & $7F)
      return (addr) 
    
    pri blipe
    
    ' "Blips" OLED.E pin to transfer data from buss to LCD
    
      outa[e] := 1                                          ' Set E High
      waitcnt((10 * US_001) + cnt)                          ' Wait 10 uSeconds
      outa[e] := 0                                          ' Set E Low
    
    
  • stevoveestevovee Posts: 18
    edited October 2013 Vote Up0Vote Down
    WOW, i'm astounded by how good this forum is. Lots of good help and I like the explanations rather than just a fix. I'll try the updated object tomorrow when I get to the lab.
  • Brian FairchildBrian Fairchild Posts: 487
    edited October 2013 Vote Up0Vote Down
    @Don

    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.
  • Don MDon M Posts: 1,572
    edited October 2013 Vote Up0Vote Down
    @Don

    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....
  • ChrisGaddChrisGadd Posts: 257
    edited October 2013 Vote Up0Vote Down
    @Don M - that initialization routine looks like it works with a power-off reset where the LCD reboots into 8-bit mode, and I'm guessing it relies on the watchdog timing out due to the busy flag remaining high when rebooting into 4-bit mode? Impressive kludge.:thumb:
    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.
  • stevoveestevovee Posts: 18
    edited October 2013 Vote Up0Vote Down
    When I use this new driver it will reset but my display wont change after it initially posts something to the display
  • Leo BotsLeo Bots Posts: 8
    edited April 2014 Vote Up0Vote Down
    Can anyone point me to an article or set of instructions for how to connect and drive an HD44780 LCD from the Activity Board? My knowledge of C programming is limited to what I have learned in the Parallax tutorials, but are there any tutorials or instructions available on how to write C programs to display text messages on the HD44780 once it has been connected and initialized?
  • Please be so kind to read this post I wrote on this same problem I had.

    http://forum.arduino.cc/index.php?topic=91659.msg3890589#msg3890589

    See attachment page 28.

    Greetings from Buenos Aires, Argentina !
Sign In or Register to comment.