<Solved> Non-functional I2C LCD

Guys and gals

I have a bit of a problem, in that my LCD doesn't display.

I have writen the core software for my project and that works just fine. All I now need to do is intergrate the LCD.

The display is a "standard" 2 x 16 display with an I2C piggyback brd. which returns an address of 0x20 when I use the I2CScanner. The backlight appears to be controlled by a SOT-23 transistor, the base being controlled by P3 of the PCF8574.

I have attempted to run the given examples for LiquidCrystal_I2C and the improved NewLiquidCrystal, by Francisco Malpartida. The examples were copy and pasted into the IDE and compiled beautifully.

The result is nix. When first powered, the backlight comes on and one line of the display shows 16 blocks, which can be varied by means of the onboard trimpot, and that is it. Whether there is a sketch running, or not, that uses the display or not. That is all I get.

Any ideas?

TIA

Fof

I have the same problem !

I followed the instructions in Project 11 Crystal Ball to use the LCD in a temperature sensor that I have created.

But the LCD does not function and I have the same issue as you reported.

I reconnected and connected several items, but the issue persists.

Ciao

Romi

There have been dozens of threads about I2C LCD problems on this forum. It shouldn't take you too long to get your devices running if you take the time to look.

Don

I do agree with Don about searching as there are MANY threads about this topic. However, there is TONs if misinformation out there from people that may be well intended but still often offer incorrect or meaningless suggestions or in some cases just plain guesses that won't help solve the issue. So it can be difficult to weed through the information.


Assuming the backpack is good and soldered/connected to the LCD correctly, and you got an i2c address from the i2c scanner, the most common issue is the library's pin configuration does not match the backpack you are using. Unfortunately, there are many libraries called "LiquidCrystal_I2C" so it is hard to tell which one you used. However with the exception of fm's LiquidCrystal_I2C they all assume a given pin mapping from the PCF8574. That pin mapping more than likely does not match the way your backpack is wired. When you used fms' LiquidCrystal_I2C you must enter the pin mapping in to the constructor. If you attempt to use the constructor without pin mapping it is pretty much guaranteed not to work as the default pin mapping in fm's library is for the ElectoFun backpack the he sells and no other backpack uses that pin mapping. In order to know what the mapping is you have to follow the traces on the PCB to see where each of the PCF8574 P0 to P7 pins attaches. Then enter the pin number in to the correct position for the LCD function it controls. It is usually not that difficult to do as often you can just look at the traces and follow them. In some cases you may have to use a ohm meter to figure out which pin goes where. Either way it only takes a few minutes. If the pin mapping is incorrect, you won't see much of any thing on the LCD and the backlight control will likely not work correctly.

Alternatively, you could try my hd44780 library. It will automagically locate the backpack i2c address and auto configure the library pin mappings. It is available in the IDE library manager so you can install it quickly and easily directly from the IDE. You don't have to alter or uninstall any other LCD library. You can read more about it here: https://github.com/duinoWitchery/hd44780

The i/o class for i2c based backpacks is called hd44780_I2Cexp. The library includes several examples down under ioClass/hd44780_I2Cexp that should "just work". I would recommend that you start off running the included I2CexpDiag sketch to test your i2c signal connections and the LCD internal memory.

--- bill

romi007: I have the same problem !

I followed the instructions in Project 11 Crystal Ball to use the LCD in a temperature sensor that I have created.

But the LCD does not function and I have the same issue as you reported.

I reconnected and connected several items, but the issue persists.

Ciao

Romi

Romi, your issue is different. Project 11 is using an LCD that is controlled by using Arduino pins, lamFof is using i2c to control the LCD. These are very different ways of controlling an LCD. I would recommend that you google "Arduino project 11" and you will find many links including videos on how to set things up and there are even some instructables that will walk you through it. If you still have issues, you should start another thread for your issue as it is unrelated to this thread.

--- bill

romi007: I have the same problem ! . . . But the LCD does not function and I have the same issue as you reported. . . .

What Bill is pointing out is that you have the same symptoms but not the same issue or problem since your interface is different.

You will get a single row of blocks on a 16x2 display when it is not initialized properly no matter how it is connected to the Arduino and even if it is not connected to the Arduino at all.

Don

Hi all.

As Don says, there is a plethora of threads covering this subject. The more I went through them, the more discombobulated I got. :-))

Thank you for the pointer, Bill. I shall try that one next.

The display and backpack, were both supplied with a starter kit. I presumed that they would work together, but no. One day I will learn, PRESUME NOTHING!!

Karma to both of you.

Fof

Bill.

Quintruplet karma for you, my lad.

As suggested, I used your hd44780 library, and ran I2CexpDiag sketch.

Lo and behold, a working display. When I ran I2CScanner it identified my address as 0x20, but you identify it as 0x27. This a conumdrum, as I have seen, in several places, the statement that if A0-A2 are not bridged, then the address would be 0x20, which is what I have and I2CScanner identified. Trouble is my backpack has A0-A2 pulled high, with 10k resistors. This, according to the data sheet, would give an address of 0x27, which it must be, as it works

Backlight issue, but that should be easy enough to fix.

Thanks again.

Fof

This is very odd. I can't imagine how the two would see different i2c addresses. The diagnostic sketch does the same thing as an i2c scanner when trying to locate a device. Did the diagnostic sketch report that external pullups were being used? All kinds of odd and not good things can happen if the pullups are missing.

There is no way say for sure to specify what bridged vs unbridged address jumpers do. Some boards pull them low and jumper them high and some pull them high and jumper them low.

What is the backlight issue? I want to make sure that there is not an issue in the library. Is this an issue of the backlight not working at all? Or is that not worked as it should like did the library get the active level wrong? So that backlight() is off and noBacklight() is on? Does the backpack have backlight jumper on it?

Can you post a photo of the backpack that you have?

--- bill

G’day, Bill

I can’t explain the difference between the 2 addresses, apart from the fact I have changed the cables from cheap chinese to a much better quality. That still doesn’t explain it, though.

I have attached a picture of the backpack.

The backlight problem is that with the diagnostic sketch the backlight seemed to be on more than off, and along with the address and pin allocation, is the message backlight off. I couldn’t see what it said when off, as I was in a location with not too good lighting, at the time. I need to rerun it tonight and get my tiny mind into what it is telling me.

I plan to examine your library just to check if I need to, or can, invert the backlight functions from my sketch, if necessary. If not then I shall just have to isolate P3 from the control transistor and drive it directly from the Uno. The only backlight jumper connects the collector to Vcc via a 4k7 resistor, allowing the transistor to control the 0v supply to the backlight.

Thanks again.

Fof

Backpack.jpg

When debugging, accurate details really matter.

I'm not understanding your comments. You said

backlight seemed to be on more than off, and along with the address and pin allocation, is the message backlight off.

implying that the library is controlling the backlight correctly but the code never sends "backlight off" to the display or serial port Then a bit later you said

I plan to examine your library just to check if I need to, or can, invert the backlight functions from my sketch,

implying that the library got the backlight control inverted and you want to change/correct it. These two statements are in direct conflict with each other.

Did you really mean that the backlight is off more than on?

Did you read the instructions and description for I2CexpDiag? and the did the LCD and serial output produce the expected results?

If the backlight control is inverted, in terms of resolving this, you are over thinking this as anything like simple backlight control inversion is easily resolved by correcting the library backlight configuration in the constructor.

The library is completely configurable manually, including canned entries for specific backpacks, should it be necessary to work around a backlight circuit that can not be automatically detected properly.

If the backlight if off more than on, and you saw "BL off" with the backlight on, it sounds like your backpack is using the backlight design on the SYDZ boards which doesn't use the transistor in the normal way and will not be able to use the fully automatic constructor.

And does the backpack have the needed external pullup resistors?

Please update us on the details of what the diag tool is reporting and what you are seeing.

--- bill

Bill, thank you for your patience.

Now that I can see what I am doing, here is an update.

When the sketch first runs, there is no BL, but the display showed LCD:0 on Line 0 with address and pin configuration on Line 1.

After approx. 10s the BL turns on 3 times, each time for about 1s, with the display, now, also showing BL Off. This is what I meant when I said the display showed "backlight off".

The Serial Monitor O/P gives all systems the green light, though it does comment about the BL Off message showing, indicating an inability to auto configure the BL. Apart from the Serial Monitor report, I also checked the brd and found the SDA & SCL lines both have 10k pullups

I now need to search out info on the constructor. Any pointers you can give me would be greatly appreciated. If it turns out to be too much of a pain to configure the constructor, I can very easily control the BL transistor from a spare IO port, but I'd prefer to do it 'properly'.

Thanks again, Bill. I was, honestly, not trying to confuse you, I just needed to unscramble my own head.

Fof

Yeah, I was assuming that was the case. So far over several years, I had only seen a handful of backpacks maybe 3 that used what I would call less than optimal backlight circuits. So I didn't focus too much on providing much information for those. I figured that they would be rare. You happen to be unlucky and have one of those backpacks. Because of the way they used the transistor, there is no way to auto detect the backlight configuration on those backpacks. The bummer is that that none of the hd44780_I2Cexp examples will "just work" out of the box on that backpack. You will have to modify the constructor. I've seen about as many of those in the past couple of weeks as I'd seen over the past 3-4 years. So I may need to do some updates to the diag sketch to make it easier for people that end up with these types of backpacks. Some of this is because I have made the code available to people before it was officially released and so documentation is lacking (Ok, non existent).

If you show me the diag output specifically the line that looks similar to this:

LCD at address: 0x38 | config: P01245673L | R/W control: Yes

From that, I can tell you what the constructor parameters need to be. The config string shows the configuration parameters that the library auto detected and the last character is the backlight active level it determined which is wrong for that backpack. That string would mean:

hd44780_I2Cexp lcd(0x38, I2Cexp_PCF8574, 0, 1, 2,4,5,6,7,3,LOW);

My guess is that your config probably matches the one I posted: P01245673L That is what I call the dreaded "SYDZ" backpack. Actually from at the photo yours is different and mine is worse as they put all the components on the other size of the PCB, so on mine if you solder it to the LCD, there is no way to adjust the contrast pot or set the address.

It works fine but because of the funky way they wired up their transistor, it fools the auto detection into incorrectly selecting active LOW when it is really active HIGH.

To configure the library, there are several different constructors including ones that accept a backpack ID. I will warn you that these non automatic constructors are subject to change and that is the main reason why the hd44780 library is still in alpha state. While they all work just fine, I may change the names used for some of parameters like expander type and backpack IDs. So while I will try to preserve the names going into the final release, just be a bit forwarned, that what we get working now may break in future releases because of some the name changes of these parameters.

There are several backpack IDs in hd44780_I2Cexp.h but if you have that config i noted above, you can use the backpack ID currently called I2Cexp_BOARD_SYDZ

So you would use

hd44780_I2Cexp lcd(I2Cexp_BOARD_SYDZ);

This will tell the library to auto locate the first backpack it sees on the i2c bus and treat it as a SYDZ backpack. You can also specify the specific i2c address if you want:

hd44780_I2Cexp lcd(Your-specific-i2c-address, I2Cexp_BOARD_SYDZ);

Just keep in mind that I2Cexp_BOARD_SYDZ may change its name to something else before the final release.

--- bill

BTW, while you can make that backpack work by altering the constructor, with backpacks being so cheap, it might be worth it to swap it out for another one so that the hd44780_I2Cexp auto configuration "just works" and you can use example code without having to constantly modify it for that backpack.

But it sounds like you have some h/w skills so you could potentially modify the board. But I wouldn't modify it to us an Arduino pin, that would make the s/w ugly as you wouldn't be able to use the hd44780 API functions to control it.

If I were going to modify it, I'd modify it to use the PCF8574 output pin same as now, but re-wire the transistor to wire it up the "normal" way.

If you want to go that route let me know, and we can discuss further. But depending on what they did in the layout of the board, it may be easier to simply deadbug another transistor to the board rather than to use the existing SMT transistor.

--- bill

Hi Bill

Great info.

As you surmised, the diag output gave:

  LCD at address: 0x27 | config: P01245673L | R/W control: Yes

With this particular project, I will use the existing backpack, as the finished project will be installed on a friend's farm, so will never need to be reconfigured.

I have a couple of options open to me, which I will play around with. I can use your I2Cexp_BOARD_SYDZ, or I can replace the existing bipolar with a P Ch MOSFET, such as AO3401 or BSS84. As you say, the new device would have to be mounted "dead cockroach" style, the existing pullup resistor would have to be shorted out, as would the 100R limiting resistor on the LCD brd. The latter being replaced with a new 100R device inserted between Drain and 0v. I would also include a 470R in the gate feed to limit the gate inrush current to about 10mA.

I am not fussed whether I s/w or h/w control the backlight, as it will be used infrequently. The backlight will only be on when a) a button is pressed and held enabling a couple of thresholds to be viewed and set, going off when the button is released and b) on for a couple of seconds, when the button is quickly pressed, to allow the battery voltage and the state of the various O/Ps to be viewed.

Again, thank you for your help and guidance.

Fof

dexcraft, please start you own thread for this. It is not related to this topic.


IamFof, could you change the title of the thread to include "I2C"? I think this will help clarify what the thread is about.

--- bill

Thread title amended.

There is also the possibility, not sure why I didn't think of this earlier, that you could just hook the output pin from the PCF8574 directly to the LCD backlight without a transistor. The part can safely sink 20ma. The backlights on the 16x2 LCDs that I have don't use that much current. (20x4 displays exceed this but you said you were using a 16x2) I would recommend you measure the backlight current of your backlight to make sure. Then you would just hook the backlight Anode to vcc and the cathode directly to the P3 pin. The autodetect should work as the VCC going through the backlight back to the P3 pin should bias P3 high when it is an input which would mean active LOW, which the circuit would now be.

This would be a much simpler mod and allow full auto configuration. The only draw back is that the backlight won't light up until the sketch calls the library to initialize it which is the case for all active low backlights.

--- bill

I do like the way your mind works, Bill. I always seem to find the most tortuous route to begin with and end up with a walk in the park.

Direct coupling to P3 definately looks the way to go. Even if I(f) is >20mA, I can always add a bit of current limiting with a small resistor.

I’m not going to have much time to look into it till the weekend, then I’ll come back with more info, and final (?) schematic of the setup.

Thanks again.

Fof

ps More Karma for you

When you look closer, see if you can fully determine the wiring/circuitry of the backlight circuit. (specific transistor, and everything that is wired to each transistor pin)

It is hard to tell from the photo, but it is also possible that the backlight circuit has a pullup on the base. If so, this will confuse the backlight active level detection. Depending on the other wiring & components of the backlight circuit, it might work to simply remove the pullup on the base. Which looks like it might be as simple as cutting a trace.

--- bill