TFT Shows a White or Blank Screen: a Hardware Checklist

A white screen is usually good news: the backlight works and the panel is powered, but the driver IC never received a valid initialization. A black screen with no glow points at the backlight circuit instead. Work through the checks below in order - on the boards engineers send us, the fault is almost always in the first four, and almost never in the glass.

Written by the Junxian applications engineering team. Figures quoted for “our models” are calculated from the 103 models on this site that carry a full parameter set, so they change when the catalogue changes.

First, read the symptom correctly

White and evenly lit: backlight on, driver IC not initialised - look at reset, SPI wiring and the init sequence. Completely dark with no glow at an angle: backlight supply - look at LEDA/LEDK and the driver current. Dark but faintly showing an image under a torch: image is there, backlight is not. Random coloured noise: the controller's RAM was never cleared - it initialised but was not written. Each symptom removes half the suspects, so spend ten seconds naming it before touching anything.

Backlight and logic are two separate supplies

A TFT module carries at least two power paths: the logic rail that runs the driver IC, and the backlight LED string, which on white-LED panels needs its own current-limited supply - the anode voltage is set by how many LEDs sit in series, not by the logic rail. Powering the logic while underdriving the backlight gives a readable-under-torchlight screen; powering the backlight with a held-low reset gives the classic pure white. Check both rails with a meter at the connector, not at the regulator.

Logic supply as specified per model. The 9-60 V entries are smart serial modules built to sit directly on a battery or charger rail without a separate regulator.

Reset timing: the most common init killer

Driver ICs specify a minimum reset pulse and a wait after release before commands are accepted, and a further delay after sleep-out before the display turns on. Development boards that tie RST to the MCU reset line violate this quietly: the MCU starts sending init commands while the controller is still waking. Drive RST from a GPIO, hold it low deliberately, release it, wait, then start the sequence - and if your library has a reset-delay setting, do not shorten it to speed boot.

The FPC connector: check it before you check your code

On assembled prototypes and small production runs, the single most frequent cause we see is mechanical: the flex cable seated at a slight angle, not pushed fully home, or the ZIF latch left open. A connector that is one contact off can still power the backlight - which produces a very convincing white screen. Reseat the cable square-on, close the latch, and inspect the contact edge for wear; a flex that has been cycled many times during debugging is a legitimate suspect on its own.

“It works when I press the screen”

If the image appears or stabilises when a finger presses the glass or the cable, you have a contact or grounding problem, not a software problem: pressure is completing a marginal joint - typically the FPC contacts, a dry solder joint on the connector, or a missing ground return that your hand is providing. It will get worse with temperature and vibration, so treat it as a hard fault. The same applies to displays that only misbehave when a motor or relay switches nearby: that is a grounding and routing issue on the host board.

VCOM and gamma: faint, washed-out or negative images

When the panel shows an image but it is faint, ghosting badly, or looks like a photographic negative, the init sequence is running but its analogue settings do not match the glass: VCOM, power-control and gamma registers are copied from a different panel's example code. These values are per-glass, not per-controller - two panels on the same ST7789 can need different VCOM settings. Use the init table supplied for the exact module rather than one found for the controller name.

Proving it is the panel - and what to do then

Before concluding the module is dead: try a known-good module on the same board, and the suspect module on a known-good board or a bare dev kit. Those two swaps separate board faults from panel faults in minutes. If the module really is at fault, tell us the model, batch and symptom - init settings are confirmed per glass batch on our side, and if a batch issue is suspected we would rather hear about it at one sample than at one thousand units.