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”
Leave a Reply
Please be kind and respectful to help make the comments section excellent. (Comment Policy)
Nice work. I really enjoy his write-ups
“Onboard 8080 microprocessor” – sigh….. did you even read the article?
Obviously not at all, perhaps the first paragraph where “controller” and “8080” were close together in one sentence.
Hey Mike,
First of all, thanks for your _very_ constructive comment. Second, I actually spent a while finding what the original author meant by “8080 interface signals” as I’m not as familiar as you with this kind of bus.
How DARE you dont know anything? Why dont you know everything that random HAD-Readers know? You should be ashamed of yourself!
my bad :(
well, kudos for at least reading the comments and fixing the mistake. you may have even learned something in the process :P
btw, parallel only has one ‘r’…
damn it! I should have stayed in bed today
Basic errors like this do little to enhance HAD’s reputation as a technical blog.
basic answers like yours do little to enhance the community.
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.
seems like a possible nice lcd for a pi project.
Like this? http://www.kickstarter.com/projects/2084212109/gameduino-2-this-time-its-personal
I see no pi?
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
Thanks, I overlooked that! That makes it kinda interesting!
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.
I see why his project was so successful – it’s all in the PCB!
“I wanted mine to be blue.” :-)
Some nice work on a reasonable display to use with a microcontroller, but does 640 x 360 really count as high resolution for a phone these days?
I think he was meaning to say high-density rather than high-resolution.
According to http://en.wikipedia.org/wiki/Sony_Ericsson_Vivaz it’s released in March 2010 which is, IMHO, probably equivalent to about late 15th century in human terms. (c:
Higher than mine. Does it matter?
It’s very nice of you to offer a cached page link to the project. I would however put the cached link as first because the first link is the one that almost everyone would click. Also, I would choose the Coral Cache any day over the Google one. Just add “.nyud.net” after the domain name of the link to load the cached one.
As an example this project link would become
http://andybrown.me.uk.nyud.net/wk/2013/10/19/vivaz-u5-lcd/
Thanks for the tip! We however took the habit of putting the author’s link first for easier parsing/referrals, but I may switch it now to switch it back later.
I’d like to see something on using the camera out of my old busted Samsung Note 2. It’s the best camera I’ve ever used on a phone and it would be great for FPV on my tri.
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.
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.
And obviously the manufacturers of the sensors and other stuff dont want to give their competitors all the info on what makes their sensor “better”
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.
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.
“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 (+,-).
Good point. He could measure the voltage needed to light them. Actually since phones tend to work on 3.7v it’s likely they are in parallel.
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.
Not all projects require 720p or 1080p ;-) If your using it for text for instance.
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.