When the screen stays blank
Five things the glass can be showing you, each ruling out something different. Checked in this order, the commonest fault takes ten seconds and the rarest takes a meter.
Look at the glass before you look at the code
Each of those five pictures rules out something different, and that is the value of looking properly before changing anything.
The order
1. Solid blocks? The display has power and the contrast is readable, and nothing has talked to the controller. If your sketch has already run, it is not reaching the display: go to step 3.
2. Lit but empty? Turn the trimmer through its whole travel, slowly, both ways. This is the commonest fault on these displays by a wide margin and it takes ten seconds to rule out. If nothing appears at either end, go to step 3.
3. Run the scanner. The sketch is
here. An address in 0x20 to 0x27 means the
bus works in both directions and the fault is in what you are printing — most
likely the address in your LiquidCrystal_I2C constructor. Nothing at all
means wiring.
4. Measure. 5 V between the display's own VCC and GND pins, not on the
breadboard rail. Then check SDA and SCK are not swapped. On an ESP32, check
Wire.begin() comes before lcd.init() — that one costs people hours because
there is no error message anywhere.
5. Levels. If it scans but the characters are unreliable, the bus is marginal. A 3.3 V board wired straight to this display is the usual reason; a clock above 100 kHz and long wires are the other two. Why it wants five volts is the argument, and the converter handbook next door is the fix.
Things that are not the fault
The library. LiquidCrystal I2C by Frank de Brabander is the one every example here is written against, and it has not changed in years. If it compiles, it works.
The display. These fail rarely, and when they do it is the backlight rather than the glass. A display that shows blocks is alive.
The order of VCC and GND. They are printed on the board and they are adjacent, which is worth one careful look — but reversing them does not usually kill the board, it just does nothing.
When it does not work
Then the contrast is not the fault, and that is worth knowing. Go to the scanner: if it finds an address in 0x20 to 0x27 the bus is fine and the fault is in what you are printing, and if it finds nothing the fault is the wiring.
Wiring, almost always, and usually the ground. A breadboard row that has been leaned on, a jumper one hole across, a supply shared with something that has since been added. Measure 5 V on the display's own pins before you reopen the sketch.
The supply is sagging. The backlight and the controller share it, and a long thin USB lead or a breadboard rail feeding a motor as well will not hold 5 V. Feed the display from a supply of its own and join the grounds.
A marginal bus rather than a broken one. On a 3.3 V board that means the level converter, or the lack of one; on any board it can mean a clock above 100 kHz or thirty centimetres of jumper wire. Set Wire.setClock(100000) and shorten the wires before suspecting the display.
They are both at 0x27 until you change one. Two devices answering to one address corrupt each other's traffic, and the symptom is usually that both misbehave rather than one. Bridge an address pad on the second, rescan, and give each display its own address in the sketch.
The board that goes between this display and any 3.3 V board, in eleven short chapters of its own.
The logic level converter handbook →Edit this page — content/books/lcd1602/when-the-screen-stays-blank.mdx
Questions about this product
See what other owners have asked, and read their solutions.
3-Pack 1602 LCD Display Module, I2C 16x2 Blue
Loading discussions…
Discuss this article
Ask about this page. The answer stays here, on the page it belongs to, for whoever hits the same wall next.