I reverse engeneered a BMW climate TFT display. Please help me identify the chip

The latest BMW 3-Series and 4-Series have a segment LCD climate display.
Whereas the 8 Series GC, X5, X6 and X7 have a much nicer looking graphical TFT. (if you buy the "4 climate zones" option, otherwise they also have the segment LCD)

my project: (in fact 2 projects in 1)
1.) upgrade my climate controls segment LCD to the TFT
2.) use the display as a data display for oil temperature, turbo preasure, etc.

1st step:
Reverse engeneer the LIN Bus communication between climate control ECU and climate control panel
Done! Fully decoded the protocol.
So I can run the control panel on my bench for further testing.

The protocol of the two panels are identical. In fact, I can even connect the X5 control panel with TFT display to my car and everything works. It just doesn't fit mechanically as the one from the BMW X Series is wider.

So the project will look like this:
My original control panel with no display connected.
ESP32 listening on the LIN Bus for the commands and driving the graphical TFT type display in "full OEM look".
Hidden touch button to switch the display between climate display and data display.

2nd step:
Reverse engeneering the TFT pinout.

Done!
Now I was able to make "screenshots" with my logic analyzer, 100% accurate and "pixel perfect".

3rd step:
driving the BMW TFT

Works! But ...

With an altered initialization sequence, I was able to display the image coming from a RA8875.
I don't know why it does not work if I init it with the original sequence.
Perhaps because I cannot make the RA8875 output exactly like the video controller used by BMW, for example only 1 clock cycle wide HSYNC impulse. RA8875's minimum HSYNC width is 8 pixels.

So I'm hoping someone with more experience with displays (and there are some of these people around here in this forum) can identify the controller used.
I had no luck searching on the net.

What I know:

manufacturer: should be Tianma (my guess, as the model number is looking like their other displays)
type: custom
model number: TM022KDHP01-02
resolution: 320x152
color depth: 16.7M
interface: 24 Bit parallel RGB
initialization via 9-bit SPI
connected to a Yamaha YGV642 video controller (feature sheet, no datasheet publicly available)

pinout:
download: https://www.dropbox.com/s/rasojh2nteo24ie/BMW%20Display%20pinout.xlsx?dl=1

initialization sequence:
download: https://www.dropbox.com/s/merk43wyhc8tgh2/BMW%20Display%20init.xlsx?dl=1
(all in HEX, [command] data ...)

[91] 00
[92] 00
[93] 00
[94] 40 28 4C 02 02 11
[61] 06 01 05 00 55 00 00 00
[95] 1A 7A 00 A5 7A 00 AA 0A 01 0A 00 9A 0A
[97] 63 02 00
[99] 10
[71] AC 5C 0F 03 04
[12] A5

"[12] A5" activates the display at the end, so looks like "DISPON".

But, as mentioned, when connected to my RA8875, I could not get a picture.
So I put "[12] A5" at the beginning and sent the init sequence very slow, byte by byte and watched, what happens.

my findings:
Commands [91], [92] and [93] can be omitted.
With "[12] A5" at the beginning, after "[94] 40 28" the display goes on.
So, the minimum init sequence is:
[12] A5
[94] 40 28

When I continue to send the next bytes, with the last data byte of the [94] command, 0x11, the screen goes black again.
Later in the sequence, the screen comes back on again, but only plain white and with kinda "shifted" pixels(?) and goes out again in the middle of the [95] sequence and stays black.

The complete, original init sequence works, if I change the last data byte (0x11) of the [94] part (which makes the display go dark) to an other value like 0x10 or 0x12!
(sure, in fact I'm sending 0x110 or 0x112 because it's 9 bit SPI without a D/C line and the first bit indicates if it's a command (bit 8=0) or data (bit 8=1).)

Even though I could get it up and running, I'd really like to have a datasheet to control it accurate and not only by guessing and "trial 'n' error".

High resolution photos of the display:

Wow! :astonished:

Driving the BMW display works fine.
I'd still love to have a datasheet for the unknown controller.

The closest I could find was a monochrome TFT display by "Midas".
The datasheet shows the following initialization sequence, but does not mention, which controller is used.

Write_Command(0xae);
Write_Data(0xa5);

Write_Command(0x61);
Write_Data(0x8f);
Write_Data(0x04);
Write_Data(0xa5);
Write_Data(0xa5);

Write_Command(0x62);
Write_Data(0x36);
Write_Data(0x0b);
Write_Data(0x0b);
Write_Data(0xa5);

Write_Command(0x33);
Write_Data(0x07);
Write_Data(0x2c);
Write_Data(0x09);
Write_Data(0x2a);

Write_Command(0x63);
Write_Data(0x09);
Write_Data(0x17);
Write_Data(0xa5);
Write_Data(0xa5);

Write_Command(0x91);
Write_Data(0x00);
Write_Data(0x16);
Write_Data(0x1B);
Write_Data(0x1C);

Write_Command(0x92);
Write_Data(0x1E);
Write_Data(0x1F);
Write_Data(0x20);
Write_Data(0x21);

Write_Command(0x93);
Write_Data(0x23);
Write_Data(0x24);
Write_Data(0x26);
Write_Data(0x28);

Write_Command(0x94);
Write_Data(0x2B);
Write_Data(0x2F);
Write_Data(0x34);
Write_Data(0x3f);

Write_Command(0x99);
Write_Data(0x00);
Write_Data(0x16);
Write_Data(0x1B);
Write_Data(0x1C);

Write_Command(0x9a);
Write_Data(0x1E);
Write_Data(0x1F);
Write_Data(0x20);
Write_Data(0x21);

Write_Command(0x9b);
Write_Data(0x23);
Write_Data(0x24);
Write_Data(0x26);
Write_Data(0x28);

Write_Command(0x9c);
Write_Data(0x2B);
Write_Data(0x2F);
Write_Data(0x34);
Write_Data(0x3F);

Write_Command(0x12);
Write_Data(0xa5);

Write_Command(0x24);
Write_Data(0x01);
Write_Data(0xa5);
Write_Data(0xa5);
Write_Data(0xa5);

Write_Command(0x22);
Write_Data(0x00);
Write_Data(0xa5);
Write_Data(0xa5);
Write_Data(0xa5);

Write_Command(0x15);
Write_Data(0xa5);

This topic was automatically closed after 72 days. New replies are no longer allowed.