Reverse Engineering The Sony Ericsson Vivaz High Resolution 640 X 360 Cellphone LCD

In our opinion, reverse engineering may be one of the best ways to tease your brain. [Andy] just did that by reverse engineering the Sony Ericsson Vivaz high resolution LCD (cached copy here). In his (very) nicely written article, [Andy] explains all the steps that led him to the result shown in the picture above. He started by finding the repair manual of the Vivaz, to discover that the display could be interfaced with 8080 type parallel signals. That meant that he could use a standard microcontroller without high speed buses to interface with it, in this case the STM32F4. Next in his adventure, [Andy] ordered the appropriate connector and took a more educated guess for the onboard microcontroller. A long Google search brought up the R61523 from Renesas. So he designed his breakout board, got it produced and a few hours later a nice picture was being shown on the LCD. He even took the time to compare the original display with the clone he found on the webs, and modified his graphics library to support this display.

35 thoughts on “Reverse Engineering The Sony Ericsson Vivaz High Resolution 640 X 360 Cellphone LCD

          1. I see the timing of the above posts, and I appreciate that you might have been starting to feel a little… “gotten at”, however, I really think you should have let that one lie.

            Mike has a fair point, it was a basic error, but perhaps one made through (admitted) lack of understanding? If this is the case, then maybe less *transcribed* detail is needed in the HaD write-up. Stick with the obvious facts.

            Something like “This guy did some pretty nicely documented reverse engineering work on a cheap, 640 x 360 phone LCD display, and then hooked it up to a stm32 (and an Arduino Mega) to boot!”, but with a little non-technical padding (similar projects, etc)?

            Realistically, anyone who is interested in the project content is going to skim the blurb for keywords, and click on through if they like the sound of that.

            My $0.02 anyway.

        1. Does it also work with the Raspberry Pi?

          Yes, it hooks up directly to SPI port on C13 on the Pi. And Raspberry Pi software support is done, so the GD library and samples/demos/games all run fine on the Pi.
          Last updated: Monday Oct 14, 10:53am EDT

          1. I have yet to see X running on it, so until then I will be quite skeptical.

            I also doubt it gets any HW acceleration from the built-in GPU, severely limiting its potential compared to the onboard LCD connector that NO ONE HAS TOUCHED.

    1. Cell phone cameras are riddles wrapped up in enigmas hidden under NDA’s. They are extremely complicated to control and much of the necessary info is trade secreted. What public info and example code is available for some cameras is incomplete and very poorly documented. I once had a talk with the guy who designed the CMUcam4 and it took a ridiculous effort to work out the interface for its cell phone camera sensor.

      1. The problem with most camera sensors (cellphone or otherwise) I suspect is that the data you get back from the sensor isn’t in a form you can use, you need specific image processing algorithms that are tied to the specific characteristics of the sensor you are using that turn the raw output from the sensor into a nice jpg or whatever.

          1. It’s interesting after reading articles on here about possible modular phones designed to minimize digital hardware waste that judging by these comments the biggest hindrance to that effort would be closed design practices. I mean there’s literally millions of broken phones out there that basically can’t be used for anything else because they’re “riddles wrapped in enigmas hidden under shattered gorilla glass”

            Kind of a shame.

  1. I rescued the half-VGA display from my ancient Palm Tungsten T3 (480×320), along with the resistive touch overlay. I wonder if something similar would work for getting it usable on some future project.

  2. “The schematic shows that there’s a single pair of power lines connected to the backlight, LCD_BL_K and LCD_BL_A. That means that the LEDs that form the backlight are arranged in serie…”
    How do I know? Cause LEDs in parallel also have single pair of power lines (+,-).

  3. I wouldn’t call 640 x 360 “high resolution” at all at today’s standard. It would be really nice if people can start reverse engineering the 720P and 1080P displays in one of the current cellphones, they would make DIY projects really useful.

    1. The parallel data bus on this display is a far cry from the packetized differential bus that is MIPI DSI, which is what a huge number of the new high-res displays use. Think printer port versus USB3.0 – one’s much easier to “fake” (from the MCU side) than the other, which requires protocol adherence and quite high speed. Add to that the fact that DSI is a closed standard, so even if we wanted to draw up some programmable logic that implements it, we’d first have to pay a few thousand dollars for the specification…

      I’ve got some very preliminary concepts for driving the iPhone 4 display kicking around, albeit pretty far down my list in priority. Requires an intermediate purpose-built IC to convert raw pixel data to DSI, and the raw data is a 24-bit parallel data stream at some tens of MHz – so in any case even if you could talk to these screens, they tend to require more horsepower than most DIY projects can afford to throw at them.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.