Two older I2C 20x4 LCDs, both work great, one won't carry out lcd.setCursor cmd

I built a device using an Arduino MEGA 2560 and a 20x4 LCD (I2C interface). Works great, I can position the cursor to any location on the screen using the lcd.setcursor(col,row) command, then write text to that location, works exactly the way I want it to.

Then built a new chassis to do the same thing, smaller chassis, but same Arduino MEGA 2560 controller, same (or very similar) 20x4 LCD (I2C interface). The hope was that both chassies would run identically, in the LCD display and everywhere else.

First I loaded a very simple "Hello, world" test program into the new chassis. It ran perfectly and printed "Hello world" in the top line of the LCD, just as I expected it to, sharp and clear. The older (larger) chassis did the same, seems that both LCDs were working correctly. So I was confident I had the wiring correct, I2C connections correct, addresses (both 0x3F) correct in the new chassis as well as the old.

Then I transferred the operational program from the first chassis to the second (smaller) chassis, hope the two would run identically, especially in the LCD display. First LCD always ran correctly and still does. But now on the 2nd (smaller) chassis, the LCD remains blank.

I wondered why both of them run "Hello World" correctly and produce excellent results, but they act differently with the operations program. Long story short, the only difference may be that the operational program uses the lcd.setCursor(col,row) command to go to a certain place on the LCD before writing, but "Hello World" does not use that command.

Long story short, I commented out the lcd.setCursor command wherever it occurred and reloaded the operation program (without lcd.setCursor) into the new (smaller) chassis. And now the LCD in that (smaller) chassis presents all the data that's written to it! The data is often in the wrong place in the smaller chassis, since I no longer use the lcd.setCursor command there to correctly position the data. But all the letters and number come out bright, sharp and clear.

Has anybody run into a situation with these I2C 20x4 LCD displays, where some of them implement all commands (such as lcd.setCursor), but others don't?

Or do I have a broken LCD in the new (smaller) chassis? They were both parts-box items, probably of different ages, both from Sainsmart.

Anybody run into this before?

Reduce the sketch size where the problem exists.

Show this to us.


Show us a good schematic of your circuit.
Show us a good image of your ‘actual’ wiring.
Give links to components.
Posting images:
https://forum.arduino.cc/index.php?topic=519037.0

Nah. If you can update the Hello World script to use cursor positioning, and it doesn't work on Display B, Display B is broken.

johngriswold:
Nah. If you can update the Hello World script to use cursor positioning, and it doesn't work on Display B, Display B is broken.

Nah.

In order to really know what is happening, you have to have more information than we currently have.

We must see the code and know which library is being used.
It is possible that there is a sketch issue like improper library initialization, incorrect use of setCursor() or a library issue that is incorrectly handling the translation from col and row to DDRAM address for setting the cursor position.
There could also be a soldering issue on the backpack, or if the LCD is really old, it could be that its instruction timing is longer than the typical timing.

Without seeing the actual code being used and knowing which library is being used, we have no way to know what the issue is.

I've not seen any instruction set issues on hd44780 displays.
I have seen some really old LCDs have slower processors on them that increases the instruction timing such that there are issues due to the library trying to send additional instructions to the LCD before previous instructions complete.

I would recommend installing the hd44780 library and use the included diagnostic sketch, I2CexpDiag, that comes with the library hd44780_I2Cexp i/o class to check things out.
Then, post the output here should there be any issues.

The hd44780 library also supports adjusting the LCD instruction timing used by the library should that be an issue.

--- bill

Sorry to be so long, folks.

I unplugged the four I2C wires from the 20x4 LCD display in the new (smaller) Arduino MEGA 2560 system, plugged in extensions, and ran them over to another 20x4 LCD in an old robot. It behaved exactly the way smaller system did: "Hello World" ran fine, showing its characters sharp and clear, but the advanced software using setCursor() left the screen blank. When I ran the version of the advanced software in which I had commented out all the setCursor commands, now the LCD in the robot worked and the text showed up fine, though in the wrong position due to lack of the setCursor command. Just like the LCD in the smaller chassis.

So now I've got two LCDs that work the same way, working fine when there is no setCursor commands, but remaining blank when setCursor is used. That argues against the idea that I broke the LCD in the smaller chassis. It suggests instead that I programmed the smaller chassis wrong somehow.

For my next trick I'll use the extension wires again, and run the I2C signals from the smaller chassis to the LCD in the bigger (original) chassis. If I had programmed the smaller chassis wrong, the LCD in the larger (original) chassis should show the same behavior as the smaller chassis, and also the same as the old robot's LCD. I know the LCD in the larger (original) chassis works perfectly when I use the setCursor command. If that LCD doesn't work with signals from the smaller chassis, then I definitely goofed up the smaller chassis somehow.

BTW, I wasn't asking folks to tell me how to fix this mess. I just wanted to know if anybody had run into the same behavior as I seem to have here: Some 20x4 LCDs can respond correctly to the setCursor command, but others can't.

Thanx all!

Should I respond, although I have no experience with this?

But I think I have seen posts about this, telling "lines" can be strangely arranged on these LCDs.

Therefore I would suggest to try different x,y cursor settings, writing a single letter, and look where it is shown on screen.

I may be wrong, but surprised no one suggested this test.

Jean-Marc

ZinggJM:
Should I respond, although I have no experience with this?

But I think I have seen posts about this, telling "lines" can be strangely arranged on these LCDs.

Therefore I would suggest to try different x,y cursor settings, writing a single letter, and look where it is shown on screen.

I may be wrong, but surprised no one suggested this test.

Jean-Marc

I mentioned this in post #3

It is possible that there is a sketch issue like improper library initialization, incorrect use of setCursor() or a library issue that is incorrectly handling the translation from col and row to DDRAM address for setting the cursor position.

The arrangement of the col/row to DDRAM address mapping isn't strange, it is not intuitive for a 20x4 display but it is well defined, but setCursor() will only work correctly if the sketch properly initializes the library and there are no other library issues.

And this is why we need more information to be able to help.
This was requested in post #1
We need to see the sketch code and know which library is being used.
Without this is it pure guessing, which wastes time.
If I were to guess, at this point, with no further information, my guess is user error or library issue
And the issue is likely one of these:

  • an issue in the sketch code.
  • an issue in the library code
  • an issue with a slow LCD taking longer for LCD instructions than the library is waiting

But since we know nothing about either the sketch or the library, I'd lean twards user error in sketch code since that tends to be much more common.

--- bill

noiasca:
The clear answer is: No. I have never run into that situation before.

Now I'm really curious how this will help you.

If nobody's ever seen it before, then chances are I broke something.

If some people HAVE seen it before, then maybe nothing's broken, that's just the way some of these LCDs program. Some can respond to the setCursor command, and some can't.

The situation in a nutshell is:

I put an 20x4 I2C LCD display in my project, programmed it with lcd.setCursor and other commands, and it responded exactly as I expected, everything worked.

Then I duplicated the chassis, with (supposedly) an identical I2C LCD, loaded the identical program in, and the display never showed any characters. Wiring seemed OK, it displayed characters fine when I ran the "Hello World" program (which did not use the lcd.setCursor command), but not when I ran the duplicate program from the first chassis. When I deleted all the lcd.setCursor commands, suddenly the new chassis started displaying characters sharp and clear.

lilabner045:
The situation in a nutshell is:

I put an 20x4 I2C LCD display in my project, programmed it with lcd.setCursor and other commands, and it responded exactly as I expected, everything worked.

Then I duplicated the chassis, with (supposedly) an identical I2C LCD, loaded the identical program in, and the display never showed any characters. Wiring seemed OK, it displayed characters fine when I ran the "Hello World" program (which did not use the lcd.setCursor command), but not when I ran the duplicate program from the first chassis. When I deleted all the lcd.setCursor commands, suddenly the new chassis started displaying characters sharp and clear.

A very important piece of information left out is what happens when you hook up the original LCD that worked with the original chassis in place of the 2nd lcd device that isn't working on the 2nd chassis?
or what happens when you take #2 lcd and hook up to chassis #1 that is working with LCD #1.

You need to be logical about trying to diagnose an issue.
It is not possible to know where to start looking since you have literally changed everything.

i.e. you are comparing LCD #1, on chassis #1, with s/w build #1 to LCD#2 on chassis #2 with s/w build #2
while the s/w is supposed to be the same, it is from two different builds & uploads.

There is no way for anyone to be able to help you given the information you have provided so far as there is critical information missing like the code and the library being used.

--- bill

bperrybap:
A very important piece of information left out is what happens when you hook up the original LCD that worked with the original chassis in place of the 2nd lcd device that isn't working on the 2nd chassis?
or what happens when you take #2 lcd and hook up to chassis #1 that is working with LCD #1.

You need to be logical about trying to diagnose an issue.
It is not possible to know where to start looking since you have literally changed everything.

i.e. you are comparing LCD #1, on chassis #1, with s/w build #1 to LCD#2 on chassis #2 with s/w build #2
while the s/w is supposed to be the same, it is from two different builds & uploads.

There is no way for anyone to be able to help you given the information you have provided so far as there is critical information missing like the code and the library being used.

--- bill

I've tried several such swaps. The problem follows the chassis, not the LCD.

Noticed the MEGA 2560 in the new (smaller) chassis, which you called #2, isn't a real Arduino Mega. It says Sainsmart on it. Apparently a copy. I've had it around for several years, a parts-box part.

The original chassis (larger, #1) has a real Arduino MEGA. So does the old robot.

So just now I lifted the real Arduino MEGA out of the robot and put it into the smaller (#2) chassis. Changed the I2C address in software and fired it up. Now the #2 (smaller) chassis works perfectly, at least as far as the LCD goes.

Either the Sainsmart I had in the #2 chassis is broken somehow, or it's not quite as faithful a copy as Sainsmart would have you believe.

As Arthur said in Holy Grail, "Our quest is at an end."

You need to be logical about trying to diagnose an issue.

I know. I'm a 66-year-old retired EE, mostly on hardware, worked on everything from weather radar DSPs to Predator flight computer to computer-controlled medical devices to a BMEWS system almost older than I am, etc. It was fun working on something relatively simple, even if my soldering isn't what it used to be (in my 20s I did Milspec assembly).

Thanx all for your help and indulgence!

I'm still not seeing enough information to be able to isolate between s/w or h/w.
We still haven't seen any code or even know which library is being used.
In post #11 it isn't clear that the two Arduino boards were running the same s/w.
post #11 is confusing in that it says the problem follows the chassis not the LCD, but yet you placed board #1 into chassis #2 and it worked.
So the problem doesn't seem to be following the chassis.

All we know from what is in post #11 is that moving board #1 into chassis #2 and uploading with code build #3 "works".
We don't even know which LCD was used that "worked".

Again, I would advise installing the hd44780 library and running the hd44780_I2Cexp i/o class I2CexpDiag sketch on both Arduino boards to test out everything.
It will report any issues it finds with the i2c signals or LCD.
If there is any issues with LCD to PCF8574 pin connections, LCD DDRAM issues or any issues setting DDRAM addresses (which is what setCursor() uses), the diagnostic sketch will flag an error.

I'll hold off any further comments until I see the results from running the diagnostic sketch.

--- bill