element14 Community
element14 Community
    Register Log In
  • Site
  • Search
  • Log In Register
  • Community Hub
    Community Hub
    • What's New on element14
    • Feedback and Support
    • Benefits of Membership
    • Personal Blogs
    • Members Area
    • Achievement Levels
  • Learn
    Learn
    • Ask an Expert
    • eBooks
    • element14 presents
    • Learning Center
    • Tech Spotlight
    • STEM Academy
    • Webinars, Training and Events
    • Learning Groups
  • Technologies
    Technologies
    • 3D Printing
    • FPGA
    • Industrial Automation
    • Internet of Things
    • Power & Energy
    • Sensors
    • Technology Groups
  • Challenges & Projects
    Challenges & Projects
    • Design Challenges
    • element14 presents Projects
    • Project14
    • Arduino Projects
    • Raspberry Pi Projects
    • Project Groups
  • Products
    Products
    • Arduino
    • Avnet & Tria Boards Community
    • Dev Tools
    • Manufacturers
    • Multicomp Pro
    • Product Groups
    • Raspberry Pi
    • RoadTests & Reviews
  • About Us
    About the element14 Community
  • Store
    Store
    • Visit Your Store
    • Choose another store...
      • Europe
      •  Austria (German)
      •  Belgium (Dutch, French)
      •  Bulgaria (Bulgarian)
      •  Czech Republic (Czech)
      •  Denmark (Danish)
      •  Estonia (Estonian)
      •  Finland (Finnish)
      •  France (French)
      •  Germany (German)
      •  Hungary (Hungarian)
      •  Ireland
      •  Israel
      •  Italy (Italian)
      •  Latvia (Latvian)
      •  
      •  Lithuania (Lithuanian)
      •  Netherlands (Dutch)
      •  Norway (Norwegian)
      •  Poland (Polish)
      •  Portugal (Portuguese)
      •  Romania (Romanian)
      •  Russia (Russian)
      •  Slovakia (Slovak)
      •  Slovenia (Slovenian)
      •  Spain (Spanish)
      •  Sweden (Swedish)
      •  Switzerland(German, French)
      •  Turkey (Turkish)
      •  United Kingdom
      • Asia Pacific
      •  Australia
      •  China
      •  Hong Kong
      •  India
      •  Japan
      •  Korea (Korean)
      •  Malaysia
      •  New Zealand
      •  Philippines
      •  Singapore
      •  Taiwan
      •  Thailand (Thai)
      •  Vietnam
      • Americas
      •  Brazil (Portuguese)
      •  Canada
      •  Mexico (Spanish)
      •  United States
      Can't find the country/region you're looking for? Visit our export site or find a local distributor.
  • Translate
  • Profile
  • Settings
Project14
  • Challenges & Projects
  • More
Project14
Show and Tell! Reverse Engineering a Phone LCD for MCUs
  • News
  • Member Updates
  • Competitions
  • Forum
  • Documents
  • Theme Suggestions
  • Polls
  • Members
  • More
  • Cancel
  • New
Join Project14 to participate - click to join for free!
  • Share
  • More
  • Cancel
Group Actions
  • Group RSS
  • More
  • Cancel
Engagement
  • Author Author: abtAmit
  • Date Created: 30 Aug 2026 3:23 PM Date Created
  • Views 145 views
  • Likes 6 likes
  • Comments 5 comments
Related
Recommended

Reverse Engineering a Phone LCD for MCUs

abtAmit
abtAmit
30 Aug 2026
Reverse Engineering a Phone LCD for MCUs

We all have old feature phones lying around in a drawer, destined for e-waste. But recently, I learned about these old devices: many of their LCDs actually use the exact same standard SPI protocols and driver ICs as the hobbyist TFT modules we buy online.

For my latest project, I wanted to put this theory to the test. My goal was to extract an undocumented LCD from a salvaged phone, reverse-engineer its pinout, and make it fully usable with standard microcontrollers (and eventually, my own custom-built MCU).

Here is how I cracked the pinout of a mystery screen using a custom PCB and a software brute-force hack.

The Salvage Operation and Live Probing

Before ripping the phone apart, I needed some baseline data. I opened the phone case, powered up the mainboard, and grabbed my multimeter. By probing the live board while the phone was running, I was able to identify the VCC and GND pins for the display.
Once I knew where power was coming from, I applied a generous amount of flux and used a desoldering wick to safely free the fragile 16-pin ribbon cable from the mainboard. I managed to manually trace out the backlight pins and confirm the ground pins.
Naturally, my next step was to do what any engineer would do: I checked the part number printed on the back of the LCD and searched for it online. Unfortunately, I hit a complete dead end. There were no datasheets, no pinouts, and no documentation available anywhere. I had a handful of unknown data pins (likely SCK, MOSI, CS, DC, and RST) and was completely on my own to figure out which was which.

image

Building a Custom Breakout PCB

If you've ever worked with bare LCD ribbon cables, you know they are incredibly delicate and really hard to solder wire directly on it. I didn't want to risk tearing the flex cable while trying to test different pin combinations.

To solve this, I designed and fabricated a custom breakout PCB.

I designed a footprint specifically to accommodate the 16-pin layout of the screen. Using plenty of flux and a steady hand, I soldered the fragile flex cable directly to the surface-mount pads on my board. This gave me sturdy, easily accessible header pins for all 16 connections. Now, the hardware was safe to experiment on.


image

The "Software Brute Force" Hack

With the hardware secure, I decided to automate the reverse-engineering process using an ESP8266. But to write a brute-force script, I first needed to know what initialization commands to send.

While I didn't have a datasheet, there is a reliable rule of thumb for salvaged phone screens: smaller displays (roughly 1.8 inches) typically use the ST7735 driver, while larger displays (around 2.4 inches with a 240x320 resolution) almost always use the ILI9341. Since my salvaged screen was a 2.4-inch panel, I confidently set up my script to use the standard ILI9341 initialization sequence.

I hooked the wires of my custom PCB up to the GPIOs of the ESP8266 and wrote a custom Arduino sketch to perform a "software brute-force" attack. The concept was simple:

  1. I created an array in the code containing all possible pin permutations for the required SPI signals (SCK, MOSI, CS, DC, RST).

  2. The code looped through this array, dynamically reassigning the ESP8266's SPI pins on the fly.

  3. Every 4 seconds, the ESP8266 would attempt to run a standard LCD initialization sequence and push a solid color fill to the screen.

  4. It simultaneously printed the currently tested pin combination to the Serial Monitor.

Visual Feedback & The Eureka Moment

I sat back, watched the Serial Monitor scroll through the permutations, and kept my eyes glued to the blank phone screen.

For the vast majority of combinations, the screen stayed completely lifeless—either staying solid black or displaying a plain white backlight.

Then, something exciting happened: the display suddenly showed random color noise and static!

You don't have permission to edit metadata of this video.
Edit media
x
image
Upload Preview
image

This static was a massive clue. In SPI displays, random color noise usually means the MOSI (Master Out Slave In) and CLK (Clock) lines have hit the right pins and are actively pushing raw data bytes straight into the frame buffer, even if the control pins (CS/DC/RST) aren't fully synchronized yet to complete a proper init sequence.

I knew I was close. A few cycles later.... The screen transitioned from chaotic color noise into a crisp, solid color fill!

I immediately locked onto the Serial Monitor to capture the pin mapping that was running at that exact second. 

The Final Result - Pushing Pixels

With the complete, verified pinout captured, I hardcoded the correct SPI pins into my sketch, and started pushing actual data to the screen using standard ILI9341 libraries.
Seeing full-color image patterns rendering flawlessly on a screen that was destined for the trash just days earlier was incredibly satisfying. Because the screen's pinout is now documented, it behaves just like any off-the-shelf SPI TFT module. I can now wire it up to any standard microcontroller.

You don't have permission to edit metadata of this video.
Edit media
x
image
Upload Preview
image

The Brute-Force Arduino Sketch

To make this work, I utilized the Adafruit ILI9341 library, but instead of using the standard hardware SPI initialization, I used the Software SPI constructor. This constructor allows you to declare arbitrary GPIO pins for MOSI and SCK.

By placing the constructor inside a 5-level nested loop, the ESP8266 tests all 120 possible permutations of the 5 unknown pins (D1, D2, D5, D6, D7). If you want to replicate this on your own salvaged screen, here is the exact code I used:



/*
 * ==============================================================================
 * ULTIMATE 5-PIN TFT BRUTE-FORCER (Software SPI)
 * 
 * Purpose: Finds the exact pinout for a screen where MOSI, SCK, CS, DC, 
 * and RST are all completely unknown. Cycles through all 120 combinations.
 * 
 * WIRING (NodeMCU ESP8266):
 * VCC -> 3.3V | GND -> GND
 * Connect the 5 unknown pins to D1, D2, D5, D6, and D7 in any random order.
 * ==============================================================================
 */

#include <Adafruit_GFX.h>
#include <Adafruit_ILI9341.h>

// The 5 safe general-purpose NodeMCU pins we are using
const int safePins[5] = {D1, D2, D5, D6, D7};

void setup() {
  Serial.begin(115200);
  delay(2000);
  Serial.println("\n--- 5-Pin Software SPI Brute-Forcer ---");
  Serial.println("Testing 120 combinations. This will take ~4 minutes.");
  Serial.println("Starting in 3 seconds...");
  delay(3000);
}

void loop() {
  int attempt = 1;

  // Nested loops to generate 120 unique permutations
  for (int i = 0; i < 5; i++) {
    for (int j = 0; j < 5; j++) {
      if (j == i) continue;
      for (int k = 0; k < 5; k++) {
        if (k == i || k == j) continue;
        for (int l = 0; l < 5; l++) {
          if (l == i || l == j || l == k) continue;
          for (int m = 0; m < 5; m++) {
            if (m == i || m == j || m == k || m == l) continue;

            // We have a unique combination! Map them to the pins array.
            int current_cs   = safePins[i];
            int current_dc   = safePins[j];
            int current_mosi = safePins[k];
            int current_sck  = safePins[l];
            int current_rst  = safePins[m];

            Serial.print("Attempt ");
            Serial.print(attempt);
            Serial.print("/120 | CS=");
            Serial.print(current_cs);
            Serial.print(", DC=");
            Serial.print(current_dc);
            Serial.print(", MOSI=");
            Serial.print(current_mosi);
            Serial.print(", SCK=");
            Serial.print(current_sck);
            Serial.print(", RST=");
            Serial.println(current_rst);

            // Initialize Software SPI with the current combination
            Adafruit_ILI9341 tft = Adafruit_ILI9341(current_cs, current_dc, current_mosi, current_sck, current_rst);
            
            tft.begin();
            tft.fillScreen(ILI9341_RED); // Try to paint the screen RED

            // Wait 2 seconds for visual confirmation
            delay(2000);
            attempt++;
          }
        }
      }
    }
  }
  
  Serial.println("\n--- Cycle Complete. Restarting... ---");
  delay(5000);
}

  • Sign in to reply
Parents
  • me_Cris
    me_Cris 3 days ago

    Is there no risk in running the "brute force" program?

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • abtAmit
    abtAmit 14 hours ago in reply to me_Cris

    It is generally safe but you could destroy the LCD by

    1. Swapping VCC and GND will instantly fry the driver IC.
    2. Feeding 5V logic to a 3.3V panel(3.3v is max while 2.8 v is recommended).
    ​The MISO Short: If the screen has a MISO (Data Out) pin mixed in with your unknowns, the MCU might drive it HIGH while the LCD drives it LOW, causing a dead short.

    It would be better if you put a 1k resistor in series with every unknown data pin. If the MCU and LCD argue over a pin state, the resistor limits the current and saves your hardware.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • More
    • Cancel
Comment
  • abtAmit
    abtAmit 14 hours ago in reply to me_Cris

    It is generally safe but you could destroy the LCD by

    1. Swapping VCC and GND will instantly fry the driver IC.
    2. Feeding 5V logic to a 3.3V panel(3.3v is max while 2.8 v is recommended).
    ​The MISO Short: If the screen has a MISO (Data Out) pin mixed in with your unknowns, the MCU might drive it HIGH while the LCD drives it LOW, causing a dead short.

    It would be better if you put a 1k resistor in series with every unknown data pin. If the MCU and LCD argue over a pin state, the resistor limits the current and saves your hardware.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • More
    • Cancel
Children
No Data
element14 Community

element14 is the first online community specifically for engineers. Connect with your peers and get expert answers to your questions.

  • Members
  • Learn
  • Technologies
  • Challenges & Projects
  • Products
  • Store
  • About Us
  • Feedback & Support
  • FAQs
  • Terms of Use
  • Privacy Policy
  • Legal and Copyright Notices
  • Sitemap
  • Cookies

An Avnet Company © 2026 Premier Farnell Limited. All Rights Reserved.

Premier Farnell Ltd, registered in England and Wales (no 00876412), registered office: Farnell House, Forge Lane, Leeds LS12 2NE.

Follow element14

  • X
  • Facebook
  • linkedin
  • YouTube