I was using a 20x4 LCD connected to Arduino Uno via a common I2C adapter board. Everything was working perfectly, including the LCD. I had it running like this for a couple of days without any problems.

My next step was to connect the LCD to a Nano instead in order to make the package smaller. The exact same code from the Uno was uploaded to the Nano, and I connected the wires in the exact same way. The major difference here was that I soldered the wires onto the Nano, because I didn't want to use headers. I did a continuity test for shorts and the connections seemed to be fine. There are only 4 wires between the Arduino and LCD adapter board: 5v, ground, SDA and SCL.

The Nano powers up fine, and the LCD powers up fine, but immediately the LCD shows the following: Corrupt LCD

That had never happened when I had the LCD connected to the UNO.

After that, the LCD stops working completely, even when I move it back to the UNO. It just constantly displays those 2 lines. (Adjusting the contrast makes the boxes appear or disappear).

After the first LCD seemed permanently broken like that, I tested it on a 2nd brand-new LCD. First I connected it to the same Uno with the same code, and everything was working perfectly. I re-uploaded that same code again to the Nano, just to make sure everything was in sync. Then upon connecting the 2nd LCD to the Nano, immediately it displayed those 2 lines. I disconnected it right away (within 5 seconds), and tried to put it back on the Uno, but still the display is corrupted. I've tried other sketches, but both of these displays seem to be broken and never display anything except for those 2 lines.

Even if I just connect 5v and ground to the LCD, no matter from what source, it just constantly displays those 2 lines.

Any ideas as to what could "break" an LCD so quickly like that, and if it's possible fix it?

Edit: As per Gerben's suggestion, I removed the I2C backpack and hooked the LCD up directly. This was the 2nd one I had broken, the one where I'm more certain of its entire (short) history. I ended up with the exact same result. Adjusting the pot only makes the boxes appear or disappear. I tried skipping the Arduino completely and giving it 5v power from an adapter, and it still has the same result. Corrupt LCD without backpack

  • Is this on the end of your long wires in your other question?
    – Majenko
    Commented Nov 1, 2015 at 16:23
  • The first LCD was, but for the 2nd LCD I tested it with short 6" jumpers. I never put the 2nd LCD (which also broke right away) at the end of the long wires.
    – Jerry
    Commented Nov 1, 2015 at 16:25
  • Also I have a 16x2 LCD (smaller) connected to a Nano via the same I2C adapter, with more complex code, and at the end of a 10' cable, and that has been working perfectly for a few weeks now.
    – Jerry
    Commented Nov 1, 2015 at 16:29
  • 2
    Try removing the backpack, and connect the LCD directly to an Arduino. That way you know if it's the backpack or the LCD that's broken.
    – Gerben
    Commented Nov 1, 2015 at 16:52
  • I just tried removing the backpack and connecting it directly, and I ended up with the same result. I added the new information to the bottom of my post.
    – Jerry
    Commented Nov 1, 2015 at 18:46

1 Answer 1


It's unlikely that you have killed the unit as this is pretty hard to do from the data interface and your picture is typical for an LCD that has not gone through the initialization sequence. A dead LCD driver will usually display nothing and what your picture shows is that the LCD controller itself is operating. If anything is dead, I would suspect the I2C interface board as this would yield the same result you are seeing. It may also be that the timing of the I2C interface is right on the edge which may explain why a long cable'd setup is working.

Note that if the initialization is not done, no other commands will work. Note also that the initialization timing and sequence of events is ABSOLUTELY CRITICAL and missing any single step or time requirement will give the result you are showing.

Starting at page 10 of this instructional PDF is my favorite and the basis of my driver that I have been using since the 80's.

The driver I use works on every display I have ever hooked to it, regardless of changes in the particular project's processor clock speed because I paid strict attention to the worst case timing requirements. If the timing of the I2C interface violates one LCD it may not violate another, i.e. one display can tolerate bad timing while another can't. There are also issues if the LCD driver uses the busy flag or not: Blind data transmission without reading the LCD's busy state will work if the LCD is fast enough and the driver is slow enough, otherwise 'No bueno!' plus the interface is not going to operate at its maximum speed. When using the busy flag (Bit 7 of the interface) there is solid handshaking which confirms (Instead of "Trusts") that the LCD is ready for the next cycle and allows operation right up to the limit of performance.

What I would suggest is that you put the interface on a logic analyzer and verify that the timing is not being violated.

Timing tolerances and variation between parts is like lug nuts on a car... If you car has 5 lug nuts per wheel, it will probably work with 3 or even 2 but NOT UNDER ALL CONDITIONS. SOME LCDs will be happy with bad timing but ALL LCDs NEVER will be.

  • Thanks! This is some amazing information. I need to read more about this, and later on I'll try some experiments, but I was wondering if anyone can answer these questions: Why would LCD initialization get messed up with the Nano but not the Uno? Also why would it get messed up with a 20x4 LCD, but not with a 16x2 LCD (which works fine with the exact same code on both the Uno and Nano, but obviously the last few characters and 2 lines are missing). BTW once I searched for "Arduino LCD initialization", I found some posts on SE and the Arduino forum about the same issue.
    – Jerry
    Commented Nov 4, 2015 at 21:42
  • Thanks for the excellent additional information. I'll accept this as the answer once I have more time to experiment and understand it fully. It seems that this information might be relevant to many people who are having this problem. I'm also interested in seeing/learning an Arduino-specific solution, for example a library that is more reliable or a modification to existing popular libraries.
    – Jerry
    Commented Nov 6, 2015 at 21:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.