Ipod Nano V6 LCD hacking

See these videos for full info

Updated May 6 2013 - added FPGA circuitry, fixed typos.
June 29 - fixed wrong CLKP/CLKN labels in clock startup sequence

Links to MIPI documents : D-PHY (Physical low-level info) DSI specification  (Command Protocol) DCS specification   (LCD commands)

Connector pinout. Mating connector is Molex 503548-1220. (Connector on display is 503552-1220)

View looking at rear of mated connector

This is the initialisation sequence from the datasheet.

I reduced the 250mS initial delay to 15mS with no obvious problems. I also tried not delaying the 3.0v supply turn-on, which also appeared to work OK.
The delay between reset and clock start sequence (see below) IS needed. I tested some shorter timings, and problems started occurring if the delay between the reset rising edge and clock start went below about 64uS.

So the mimimum intialiation would seem to be :  +3v and +1.8v on, reset low,   Wait >100uS, Reset High, Wait >100uS, Clock start sequence

I couldn't easily test any constraints on powerup to reset-high time due to FPGA configuration time. 

Clock startup sequence

At startup, the following sequence is needed to enable the clock receiver. This is the same as the sequence for the data bus.
On the ipod, the clock runs continuously - I don't know if this is necessary - it may be possible to disable the clock between commands, or even during a command between btyes - to be tested.  Non-continuous clock is an optional feature of the DSI spec. However it did work when the clock period varied from cycle to cycle when I was testing frequency range, so clock gaps between bytes. I've tested at clock rates down to 2MHz. Issues below that may have been due to my test setup.
In the ipod, the clock runs at 110MHz.
The framerate is NOT derived from this clock, but from an internal oscillator.
The absolute polarity of the LVDS clock does matter  - the sync byte will not correct for wrong clock phasing.

Data packet

A packet can contain one of more commands, Only one start byte (0xB8) is required to start the packet ( i.e. not between commands). I don't know if gaps are allowed between commands within a packet - if they are, they may need a new start byte.

The data lines must stay below 0.5V during high speed (LVDS) mode. LVDS swing is typically +/-100mV relative to a +200mV baseline.
I have found that a small positive bias was needed on the DN line on some displays - not investigated fully.

From MIPI D-PHY spec :

Data start - entry to high speed mode

Start byte sequence

End of data packet, exit from high-speed mode
A data line transition is needed at the end of the last byte. As the last byte will be CRC, which is ignored, a simple way to achive this would be to set the second CRC byte to 0x00 and send an extra 0xFF byte (not included in the payload byte count) to generate this transition.

This is the hardware configuration I used to drive the display from a Lattice MACHXO2 FPGA.. The 1K pullup on DN was a last-minute fix when I found some displays didn't work - not looked in detail at the exact effect - could just have been ground shift pulling the line slightly negative without it.
Note I didn't use the clock output from the DDR IO cell, as this shares tristate control with the data line, so you can't tristate the data bus without also
tristating the clock.
The sequence to enter high speed mode on the data lines (Clock is same as data) is as follows :

LVDS tristated,DN bias and DP bias high
DP bias low
DN bias low
LVDS output enable, output low (DP=0,DN=1)

Using non-differential signals

I have done a quick test to confirm that it does work with non-differential signals, i.e. holding one of the DP/DN and CLKN/CLKP lines to a fixed level. I haven't done any optimisation on component values yet.

Command protocol

Two commands are required to initialise the display - exit sleep and display on. They can be in either order. After this, sync pulses will start and the display will show random garbage unless previously sent a frame of image data.

The initialisation data can be merged with display data, which is useful if data is coming from a preformatted source where commands can be embedded along with teh display data, e.g. FPGA playing back from SPI flash.
So the full sequence to initialise and send a frame of 16bpp data would be :

It is possible to send more than one line per command (tested with 2 lines, coudn't do more due to FPGA buffer size limit), but there is a 64K limit imposed by the 16 bit payload length field.
As multiple commands can be sent in one packet, it should be possible to send a whole frame in one packet, i.e. only entering high-speed mode at the start and exiting at the end.
It may also be possible to just stay in high speed mode all the time, which would be useful if the clock doesn't mind being stopped between bytes, as you wouldn;t need to do the enter/exit high-speed mode every time . *To be tested*

Packet formats from MIPI DSI spec

SoT is the entry to high-speed mode, plue the 0xB8 start byte. EoT is a transition after the last bit, then exit from high-speed mode.

Short packet

Long packet

The checksum (actually a CRC) is ignored by the display so does not need to be calculated.

ECC calculation

ECC values are listed for the basic comamnds in the table above. For others, they can be calculated as follows

The ECC  byte comprises six parity bits calculated from various bits in the header as follows :

P7=0
P6=0
P5=D10^D11^D12^D13^D14^D15^D16^D17^D18^D19^D21^D22^D23
P4=D4^D5^D6^D7^D8^D9^D16^D17^D18^D19^D20^D22^D23
P3=D1^D2^D3^D7^D8^D9^D13^D14^D15^D19^D20^D21^D23
P2=D0^D2^D3^D5^D6^D9^D11^D12^D15^D18^D20^D21^D22
P1=D0^D1^D3^D4^D6^D8^D10^D12^D14^D17^D20^D21^D22^D23
P0=D0^D1^D2^D4^D5^D7^D10^D11^D13^D16^D20^D21^D22^D23

Here is some Visual Basic code (sorry!) to calculate the ECC.
It takes a 3 byte string of binary values for the packet header, and returns a 4 byte string including the ECC

Here is some C code

Content creation

I highly reccommend Virtualdub for creating uncompressed AVIs for playback. It supports oddball output resolutions, and nonstandard formats like 1bppp mono and 16 bit RGB.
Virtualdub's 16 bit 565 format matches the input format for this LCD. 24 bit RGB matches the LCD if the BGR order bit is set to 1.
To improve the quality of images displayed as 16bpp, I have written this filter for virtualdub, which uses dithering to improve greyscaling, avoiding banding on colour gradients etc.
To format an arbitary video file :

Load file into virtualdub (accepts AVI,MPEG and bitmap sequences)

Video->filters->Add resize, set to 240x240 pixels.
Video->Colour Depth->16 bit RGB (565)
Audio -> No audio
Video->Compression->No compression
Set in and out markers if you only want a section of the file
File->Save as AVI

Parsing AVI files
Uncompressed AVIs are fairly easy to handle - after parsing the header, you get packed frames of data, with an 8 byte header between each frame. The frames are in a format suitable for sending directly to the display with no further processing.
Here is some sample code in C and VB6

Dimensions

List of commands with ECC for different numbers of lines (16bpp mode)

Lines (bytes = lines*480+1)  : write command including ECC