Arduino Nano - LCD just blocks until reset

Other Hardware Displays
1

I have an Arduino Nano, powering a 20x4 LCD display with I2C interface powered from its 3v3 pin and sharing a common ground. Power to the Arduino comes from an 11.1V Lipo going through some resistors and a voltage regulator which then connect to the 5V and GND inputs of the Arduino (or USB power).

To remove any code issues I've uploaded ONLY the LCD-Blue-I2C test code for my particular display and hard coded 2 lines of messages.

The Problem:

when you power up the Arduino, the LCD display shows line 1 all blocks and line 3 all blocks. And does nothing else.

However - if you press RESET on the Arduino, it reboots and works 100%!

Also, if you connect Serial Monitor (which causes a reboot) it works 100% and the display starts showing my custom messages.

When back on its own power (i.e no USB connection) and you start-up, you again just get blocks. If you press RESET on the Arduino suddenly it works 100% and my LCD displays the messages.

I've tried 3 different types of power to the Arduino it makes no difference. I cant keep having to press RESET every time i turn it on, as its going to be in a closed case which i dont want to have to open every-time. It should be just booting up and running when power comes on without needing to be reset thereafter?

Can anyone figure out the problem?

2

The lock up is probably occuring when the sketch tries to initialise the LCD as the LCD is also being reset at power up and it might not be "ready" to receive the commands. Try adding a 1s delay at the start of setup().

If that does not work try some experiments to see where it is locking up in the sketch. eg. turn on a LED at the start of setup() and off at the end and see if it stays on or not. You can then narrow down the code line that is locking up be moving the LED off command line to an earlier point in the code

3

I think, @bodmer is right.

If his advice doesn't work, then I would give the newly available HD44780 library (can be installed via IDE's library manager) a try as Bill Berry (author of the library) has quite an extensive understanding of HD44780 based LCD's and taken a lot of precautions (like timing issues) in his new library.

4

Most of the libraries I've seen have more than adequate delays in their initalization code to account for powerup conditions, but it still might be an issue worth looking into.
If the i2c LCD uses a PCF8574 expander, and the LCD wasn't ready when the AVR started trying to initialize the LCD, it might fail to initialize the LCD but then I'd think that further output to the LCD would generate some garbage rather than leave the LCD looking like it just powered up.

  • What happens when you upload the code? Does the display remain in its current state or does it work?

  • What library are you using?
    Obviously, I'd recommend using the hd44780 library, but it might help to know which library you are currently using.
    You can read more about hd44780 here: hd44780

My main concern is over how things are powered.
It kind of sounded like you are powering the AVR at 5V but the LCD at 3v.

  • What LCD are you using? Is it really a 3v LCD?

It also sounds a bit funky to have the initial voltage going through some resistors before a voltage regulator.

  • Can you go over how things are powered again in more detail?
    Specifically,
  • What voltages are being used to power the AVR vs the LCD and how are the pullups on I2c signals are wired up?
    It sounds like there is a mix of 3v and 5v devices.
    Normally, when mixing 5v and 3v you will use level shifters.
    It can be done without level shifters but it requires running the bus at 3v which means the 5V device will receive "HIGH" signals that are out of spec but typically work. If the bus is wired to 5V the 3v device will receive signals are too high and could potentially damage the device.

I've done testing when 3v masters, like ESP8266, and running the i2c bus with 5v slaves with 3v pullups and that seems to work ok. I've not tried it the other way around with a 3V slave and a 5V AVR using 3v pullups.

--- bill

5

As Bill noted the LCDs are typically designed to work from 5V not 3.3V. If you swap to 5V you will need to adjust the contrast pot. as well.

I gues you have read this setup guide.

6

Hi,

Sorry, i typed this last night and was a bit sleepy :slight_smile:

The LCD is on the 5V rail that is supplied on the breadboard.

I've built it exactly like this: http://picpaste.com/3a9327cf78a473c227c27bbd86079da3.jpg

So the LCD screen is getting power from the same source as the Arduino. I was mixed up with the 3.3V as thats what the SDCard reader is getting.

So you think i should change from the LiquidCrystal_I2C.h library to another one?

I have tried a 5 seconds delay before lcd.begin() but no effect.

7

You answered the questions about the power, but I had 3 other questions in post #3 that have not been answered yet.
(They were all marked with a dash)

The 3rd question is now very important as you say you are using an i2c/lcd library (we still don't know which one - there are many named LiquidCrystal_I2C) since the fritzing diagram you have shown, that you said "I've built it exactly like this", is only showing a single pin being wired to the LCD and that pin is not even an i2c pin.
There is no way an i2c backpacked LCD could ever work with that wiring.

Details matter. We need accurate details to be able to help.

BTW, in that fritzing diagram your SD breakout is wired directly to5v pins on the Arduino. That is not good. You will need to use level shifters on the data pins as the breakboard shown in the diagram does not have them.

--- bill

8

Hi Bill,

Apologies, see reply below.

First, regarding the LCD - I could not get the exact LCD model they mention in that design so i bought this one :
https://arduino-info.wikispaces.com/file/view/YwRobotLCD-CU-450.jpg/341645320/YwRobotLCD-CU-450.jpg

Its the same thing, just not made by that brand its a "Funduino". I wired it exactly as per these instructions:
GND - GND
VCC - 5V
SDA - Pin A4
SCL - Pin A5

To answer your other questions;

  • What happens when you upload the code? Does the display remain in its current state or does it work?
    SINCE THE UNO IS ON, THE DISPLAY REMAINS IN THE WRONG STATE, BUT AS SOON AS THE UPLOAD IS COMPLETE AND IT REBOOTS, IT WORKS 100%. BUT NEXT TIME I POWER DOWN AND POWER -UP ITS BACK TO THE SAME UNTIL ITS RESET.

  • What library are you using?
    I'M USING THIS ONE: NewliquidCrystal_1.3.4.zip

My main concern is over how things are powered.
It kind of sounded like you are powering the AVR at 5V but the LCD at 3v.

  • What LCD are you using? Is it really a 3v LCD?
    NO THAT WAS A MISTAKE, ITS BEING POWERED ON THE BOTTOM 5V RAIL THAT THE ARDUINO GETS POWER FROM.

It also sounds a bit funky to have the initial voltage going through some resistors before a voltage regulator.

  • Can you go over how things are powered again in more detail?
    Specifically,
    11.1V GOES TO A HID RFID READER DIRECTLY
    11.1V GOES TO THE CIRCUIT WITH THE 2 RESISTORS AND VOLTAGE REGULATOR TO BRING IT DOWN TO THE VOLTAGE FOR THE ARDUINO + LCD DISPLAY. ALL GROUNDS ARE COMMON.

  • What voltages are being used to power the AVR vs the LCD and how are the pullups on I2c signals are wired up?
    I DONT UNDERSTAND THE Q?

9

Ok. I understand your setup.
And it sounds like there is only a issue from a power up coldstart.
And all warmstarts work just fine.

fm's library does a 100ms pause which should be more than long enough
(my hd44780 library uses the same delay).

In terms of power, your comments don't match the fritzing diagram:

NO THAT WAS A MISTAKE, ITS BEING POWERED ON THE BOTTOM 5V RAIL THAT THE ARDUINO GETS POWER FROM.

According to the fritzing diagram, The arduino gets power directly from the voltage regulator and the lower 5v breadboard rail is powered from the 5v output from the Arduino board.
The voltage from the regulator is not directly supplying the LCD .
The voltage regulator output is being fed to the Arduino board, which has another regulator to lower the 10.5v down to 5v.
(I'm assuming this is the way you have things connected)

No supply power is going through the resistors, they are only being used to set the output voltage for the regulator.

The last question was about the voltages since if the AVR was at 5v and the LCD was a 3v there are issues with handling the pullups on the i2c bus(es).

There could still be a power up issue related to the time the 100uf cap takes to charge up.
Typically much smaller caps are used - the reference design uses 1uf.
I would have thought that if this were the case, then the 5 second delay you said you added before lcd.begin() should have allowed all the voltages to stabilize.

Of particular note is that the backpack does not appear to have the required pullup resistors on the i2c lines.
This can cause issues.

If you want to test your i2c signals and do a diagnostic on your LCD, you could install the hd44780 library and then run the I2CexpDiag sketch.
You can install it directly from the IDE using the library manager and you don't have to alter or uninstall any other library.

That will tell you if you have the proper pullups on your i2c bus.
If you don't have pullups, then will need to add them.

After you have run the I2CexpDiag sketch, let is know if you have the required pullups.

If there wasn't an issue with the pullups, you also might want to look at using a smaller cap like a 1uf or possibly a 10uf and see that corrects things.

--- bill

10

I notice you mention the capacitor.

The electronics shop did not have the 50V capacitor in stock so they said a 63V will work. Could that change anything?

Thanks,

11

No. It isn't a voltage value issue. That is a maximum for the part.
The actual voltage is determined by the supply and the regulator settings.
It is the value. 100uf vs a smaller value. For a given voltage (around 10.5v in this case), a 100uf cap will take longer to charge up than a 1uf or a 10uf.
But if you added a 5 second delay before begin() this extra time shouldn't matter.

You should try the hd44780 library and run the diag sketch.

--- bill

12

Okay I installed your library, and the test script and uploaded it.

The output from the serial is here:
http://pastebin.com/TqPLcGsz

The result? I've disconnected the USB and powered it on-and-off 10 times and ALL 10 times it works 100% and displays the LCD test data.

So, now what? :slight_smile:

13

neoprema:
The result? I've disconnected the USB and powered it on-and-off 10 times and ALL 10 times it works 100% and displays the LCD test data.

Wait, What? USB?
I know you mentioned using USB in the original post but the fritzing diagram shows using a battery and a voltage regulator.
You must be consistent when trying to diagnose issues. ANY change alters things and can potentially add or remove other or existing issues. It could even bas as subtle as bumping a wire that makes/breaks a connection.

From the diagnostic output, your board does not have pullups on it so your i2c signals are relying on the internal AVR pullups which are not strong enough and are way of spec. While it can often appear to work, it is a bit of a ticking time bomb that might go off at some point in the future and cause i2c issues.

The diagnostic sketch is very different from a normal sketch so the fact that it may come up every time doesn't really help figure out what the issue is.

There could still be issues related to:

  • using the battery and voltage regulator.
  • a timing issue in fm's library

The only way to know for sure if there is timing issue in fm's library and not in hd44780 would be to run the exact same sketch with both libraries.
i.e. create two versions of the same sketch; one that uses LiquidCrystal_I2C and one that uses hd44780_I2Cexp and run them back to back on the exact same setup to see if one works and one fails when using the battery.

But first and most importantly, you need to add the required i2c pullup resistors to ensure the i2c bus is working properly.

If you fix the pullups and then LiquidCrystal_I2C fails but hd44780 works then it is likely to be a LiquidCrystal_I2C issue.
If both fail, then is likely to be some sort of power issue related to the regulator and the large capacitor.

--- bill

14

You know the USB cable from the Arduino to the Mac, so I can upload the software and access the Serial data?

It also powers the Arduino so I was mentioning that I unplugged it and continued with my tests...

I changed my program's library to use the hd44780 lib and so far i've tested the system 10 times again and its working perfectly.

Is it safe to say my problem was the LiquidCrystal lib I was using?

15

neoprema:
You know the USB cable from the Arduino to the Mac, so I can upload the software and access the Serial data?

It also powers the Arduino so I was mentioning that I unplugged it and continued with my tests...

Sure you can use USB for power and I understand what you are doing with USB power, it is just that we started off testing with the voltage regulator and then things switched to a different environment which can have very different power up reset sequence & timing.

neoprema:
I changed my program's library to use the hd44780 lib and so far i've tested the system 10 times again and its working perfectly.

So are you saying that without changing anything, you can upload the version of the sketch that uses LiquidCrystal_I2C and it fails the testing, and then immediately upload the version that uses hd44780 and it works?
It is very important to test the exact same set up with both sets of code.

Did you also try that same double test using the battery and Voltage regulator?
That is a different environment that could be creating a long/slower voltage rise at power up given the large capacitor which could potentially cause a power up issue, particularly when there are no pullups on the I2C bus signals.

Is it safe to say my problem was the LiquidCrystal lib I was using?

If the same exact sketch is run and works with one library but not the other, then it is likely to be a library issue, but given that the i2c signals are missing proper pullups the issue still could be related to poor i2c signals.Without looking at the signals on a scope, it is very difficult to be certain that the missing pullups is not causing these issues.

hd44780 has some slightly longer delays during the initial 4bit mode initialization.
It could be that your particular LCD is a bit slower than the reference design timing and needs just a bit longer and the longer delays in hd44780 during initialization allow it to reliably work.

Or it could be that the longer initial delays in the hd44780 initialization are masking some i2c signal issues due to the missing pullups.

--- bill