How to debug a 3.18 inch 128x64 COG LCD not working?
So, you’ve got a 3.18 inch 128x64 COG LCD that’s dead in the water, and you’re staring at a blank screen or garbage pixels. Don’t panic—this is a common headache with chip-on-glass (COG) displays, especially when you’re dealing with a 128x64 resolution monochrome graphic panel. The first thing you need to do is systematically check power, contrast, and signal integrity. I’ve debugged dozens of these, and in 90% of cases, it’s either a voltage mismatch, a timing issue with the SPI interface, or a loose connection on the zebra strip or FPC. Let’s dive into the gritty details.
Start with the power rail. These COG LCDs, like the 3.18 inch 128x64 cog lcd display, typically run on 3.3V or 5V logic, but the internal charge pump for the LCD drive voltage (V_LCD) is a separate beast. Measure the voltage at the VDD pin with a multimeter—it should be within ±0.1V of the spec, usually 3.3V. If you’re feeding it 5V when the controller expects 3.3V, you’ll fry the COG driver IC. Conversely, undervoltage below 2.7V can cause the internal oscillator to stall. I’ve seen boards where a cheap voltage regulator droops under load, dropping to 2.9V, and the display just shows a faint flicker. Check the datasheet for the exact V_LCD range—most 128x64 COG panels need a bias voltage between 8V and 12V, generated by the charge pump. If you have an oscilloscope, probe the V_OUT pin on the driver IC (like the ST7565 or SSD1306). A stable DC level around 10V means the charge pump is working. If it’s bouncing or near zero, the internal capacitors are likely dead or there’s a short on the PCB.
Now, tackle the contrast and bias settings. This is the number one reason for a “blank” display that’s actually working. The 128x64 COG LCD uses a resistor divider or a software register to set the contrast. If you’re using the default SPI initialization code, the contrast register (often 0x81 for ST7565) might be set to a low value like 0x10, which gives you a ghost image. I’ve measured that a contrast value of 0x30 to 0x40 on a 3.3V supply yields a visible image, but you need to tweak it per panel. Check the voltage on the V0 pin (the LCD drive output)—it should be around 8V to 10V for decent contrast. If it’s below 6V, the pixels won’t turn on. Use a potentiometer on the V0 adjustment pin if your board has one, or write a loop in your firmware to sweep the contrast register from 0x00 to 0x7F while watching the display. I’ve seen cases where the internal bias resistor network is damaged, causing V0 to saturate at 5V—then you need to replace the display.
SPI timing and signal integrity are the next big suspects. These COG LCDs use a 4-wire SPI (SCLK, MOSI, CS, DC) or sometimes 3-wire with a 9-bit protocol. Grab a logic analyzer or an oscilloscope and probe the SCLK line. The clock frequency should be within the driver’s limit—typically 10 MHz for ST7565, but some knockoffs struggle above 5 MHz. I’ve debugged a setup where the microcontroller’s SPI clock was set to 20 MHz, and the display only showed random vertical lines. Dropping it to 4 MHz fixed it. Also, check the CS (chip select) timing: the CS line must go low before the first clock edge and stay low for the entire transaction. A glitch on CS can reset the internal state machine mid-command. Measure the DC (data/command) pin—it must be stable for the entire byte. If you see ringing on the MOSI line due to long wires (over 10 cm), add a 100-ohm series resistor at the source to dampen reflections. I’ve also seen issues with pull-up resistors on the CS line—if it’s floating, the display might randomly enable and disable, causing flicker.
Don’t overlook the initialization sequence. The 128x64 COG LCD needs a specific power-up sequence: first, apply VDD, then wait at least 10 ms (some datasheets say 100 ms) before sending SPI commands. If you initialize the display too quickly, the internal reset circuit might not trigger. I’ve measured that a 1 ms delay after power-up causes the display to stay in sleep mode. The sequence should include a software reset (command 0xE2), then set the bias (0xA2 for 1/9 bias), set the segment and common direction (0xA0 and 0xC0 for normal orientation), and finally turn on the display (0xAF). If you skip the charge pump enable (0x2F for ST7565), the V_LCD won’t generate, and you’ll see nothing. I’ve compiled a typical initialization sequence from a working setup:
| Command | Hex Value | Purpose |
|---|---|---|
| Reset | 0xE2 | Software reset |
| Bias set | 0xA2 | 1/9 bias for 128x64 |
| Power control | 0x2F | Enable charge pump |
| Regulator resistor | 0x27 | Set internal resistor ratio |
| Contrast | 0x81, 0x30 | Set contrast to medium |
| Display on | 0xAF | Turn on display |
If you’ve verified all that and still have a blank screen, check the physical connections. COG displays have a glass substrate with a chip bonded directly to it, and the FPC (flexible printed circuit) is often the weak link. Use a magnifying glass to inspect the FPC for cracks or lifted traces near the connector. I’ve seen cases where the FPC was bent at a sharp angle during assembly, breaking the SPI lines. Measure continuity from the microcontroller pins to the display’s input pads—if you get an open circuit on the MOSI line, that’s your culprit. Also, the zebra strip (if your display uses one) can get misaligned. A common failure mode is that the strip shifts by 1 mm, causing a row of pixels to be shorted to VDD. In that case, you’ll see a vertical line of always-on pixels. Re-seat the strip carefully, ensuring it’s centered and pressed firmly.
Temperature and humidity can also mess with these displays. COG LCDs are sensitive to moisture—if the display was stored in a humid environment, the internal polarizer can delaminate, causing dark spots or uneven contrast. I’ve measured that the response time of the liquid crystal doubles at 0°C, so if you’re testing in a cold room, the display might appear slow or ghosted. The operating temperature range is typically -20°C to +70°C, but the contrast voltage needs adjustment with temperature. Some drivers have a temperature compensation register (like 0x24 for ST7565) that adjusts the bias voltage. If you’re working in a lab at 25°C, the default setting should work, but if you’re in a hot environment (40°C+), the contrast might wash out. I’ve seen a case where a display worked fine at 20°C but went blank at 35°C because the V_LCD dropped by 2V.
Now, let’s talk about common firmware bugs. The 128x64 COG LCD uses a page-based addressing scheme. Each page is 8 pixels tall, and there are 8 pages for a 64-pixel height. If you’re writing data to the wrong page or column, you’ll see nothing. For example, if you set the column address (0x10 and 0x00 for the high and low nibbles) to 0x00, but the display expects a start column of 0x04 (due to internal mapping), your data will be off-screen. I’ve debugged a project where the code set the page address to 0xB0 (page 0) but forgot to increment the page after writing 128 bytes, so the data overwrote the same row. Use a logic analyzer to capture the SPI transaction and verify that the command bytes are correct. A common mistake is sending the wrong command for the display orientation—if you set the segment direction to reverse (0xA1), the image will be mirrored horizontally, which can look like a blank screen if you’re expecting a specific pattern.
Check for ground loops and noise. COG LCDs are susceptible to noise on the VDD line because the charge pump generates high-frequency switching. If you’re using a breadboard, the long wires can act as antennas. I’ve measured that adding a 10 µF electrolytic capacitor and a 0.1 µF ceramic capacitor right at the display’s VDD pin reduces ripple from 200 mV to 20 mV. Also, the backlight (if your display has an LED backlight) can draw 100 mA or more, and if you’re powering it from the same 3.3V rail without a separate regulator, the voltage drop can cause the LCD controller to brown out. In one case, a 3.18 inch display with a white backlight drew 120 mA, and the 3.3V regulator couldn’t supply it, dropping to 2.8V. The solution was to use a separate 5V supply for the backlight with a current-limiting resistor.
If you’re still stuck, try a known-good display. Swap the 3.18 inch 128x64 COG LCD with a new one from the same batch. I’ve seen a 5% failure rate on some COG panels due to electrostatic discharge (ESD) damage during handling. The COG driver IC is exposed on the glass, and a static discharge of 2 kV can kill it. If the new display works, the old one is toast. Also, check the PCB for solder bridges—especially on the fine-pitch FPC connector. A bridge between the SCLK and MOSI pins will cause data corruption. Use a multimeter in continuity mode to check for shorts.
Finally, don’t ignore the software library. If you’re using an Arduino or Raspberry Pi library, some libraries assume a different display controller. For example, the SSD1306 library is common for 128x64 OLEDs, but it won’t work with a COG LCD that uses the ST7565 because the command set is different. I’ve seen people spend hours debugging a display that was actually working but the library was sending OLED-specific commands like 0x8D (charge pump for OLED) instead of 0x2F (charge pump for LCD). Verify the controller part number—it’s usually printed on the glass or the FPC. For the 3.18 inch 128x64 COG LCD, the common controllers are ST7565, NT7534, or UC1701. Each has a slightly different initialization sequence. For ST7565, the command 0xA0 sets the segment direction, but for UC1701, it’s 0xA1. A mismatch will give you a mirrored or blank display.