Help discovering LCD COG types or communication protocol - Page 1
Forum section: electronics / repair

author: benneton
author_rank: Contributor
timestamp: September 03, 2021, 07:49:52 pm
content: I own a device that has faulty 256 x 64 dot matrix display (flat cable damage + some bug infestation). After a disassembly I discovered that display is connected via 20-pin connect (soldered pins).I connected the logic analyzer and got the signals from 12 pins. Every four seconds signal from picture 1 is appearing with the new data. Highest frequency is 200khz.Picture - zoom level 1:Zoom level 1Picture - zoom level 2 - beginning of the signal:Zoom level 2Signals on 1,2,3,4,8,9,10,11 look like data (8-bit)Could you point me to some reading material or video that shows professional approaches to reverse engineering where signal is present but lcd is faulty and there is no info about the COG drivers.Could you recommend any display controller simulator (that uses popular communication protocols with matrix lcd/tft displays) that could run on the computer? I would like to test the data and pixel output before soldering the real replacement device... (For this case I figured out that the easiest solution is to write the D0-D8 directly as a matrix of characters with any programming language - e.g. python)I've used DSView with DS Logic Analyzer. I posted the data from this measuring to the github (can be opened with DSView tool):DSLogic View Data >>https://github.com/vladimirdjuricic/dsviewdata/blob/master/DSLogic-la-210821-144614.dslAdditional informationDisplay manufacturer: TrulyModel: mgg2257b2-eDisplay's driver driver NOT present at PCB (has two COG present - direct driving from MCU)MCU: Motorola's MC9S08GB60AAfter a bit of investigation I discovered that this is a LCD direct drive.Two drivers are COG type and those are directly connected to MCU (HCS08) via 13 pins (I traced the connector pins via resistors to cogs) of which 12 are having updated signals. COGs are also sharing 11 pins. This device is at least 10 years old and it seems that manufacturer has selected the cheapest way to save some money to create a GUI (without controllers - 8080/6800 etc...).I would definitely like to learn more about this approach so maybe this question could be useful for others as well.Idea is to get the info about the COG. Not sure could this be custom made COG?It is 256x64 display but it has only two COGs... I was expecting 4x KS0108 and one KS0107 (or similar). It is 2x 128x64 as it seams. I have no idea which ones... (device is 10-15 years old...)Could be ST7565/ST7565V...

author: MegaVolt
author_rank: Frequent Contributor
timestamp: September 06, 2021, 12:50:04 pm
content: The first thing you need to do is to understand the model of the controller. Next you need to find the datasheet for it. The rest is easy.The controller can be identified by exchanging with it. There are certain registers that store the model name.The description of these registers can be found in the arduino libraries)))) One of them I have attached.There is also a lot of information about the types of controllers here:https://www.crystalfontz.com/controllers/

author: benneton
author_rank: Contributor
timestamp: September 06, 2021, 08:25:38 pm
content: Thanks a lot for this list and your reply! I already managed to decode the data by leaning on KS0108 timing and by super clear explanation by Mr. Peter Vis . This list you sent will be useful to explain other lines beside CS1, CS2 and D0-7 and other protocols. I hope I will post my findings and the link to sigrok decoder I made to decode KS0708 very soon. Currently on my phone, looking forward to look at the sourcecode from zip tomorrow. Thanks again!Btw, D0-D7 are 11,1,10,2,9,3,8,4. CS1 and CS2 -> 0,5.. that choppy line that has 2, 3, 3, ... 2, 3 pulses is so weird. Cannot compare it with anything in KS0708 datasheet. Probably it is not that driver at all but similar data paging...

author: benneton
author_rank: Contributor
timestamp: September 08, 2021, 11:40:43 am
content: Regarding understanding of controller - that is the whole point. Can't discover which one is it. No number on cogs, nothing useful from model of display. That's why I am trying to discover this by looking at the timings from pins.I assembled fragments from D0-7 data. However, sometimes through the communication sequences only partial data is being sent or this could be due to bad captured data with the decoder I created for Sigrok decoder lib - need to double-check. I assumed that it is sometimes full display refresh, sometimes parts of it, not certain.. Now I will try to detect commands from other lines in combination with data lines. Maybe I will be able to discover the chip by commands that are sent (addresses, etc).This communication is sending data right away after CS1 or CS2 is enabled and an short burst on PIN 7 (15us later from 835us of enabled state). Bit time is 6us. 835/6 = ~139. 4 times this for CS1 and 4 for CS2. Let's say it is 128 columns x 8bits x 4 "pages" per chip. 256x64 could be confirmed.CS1 gives one page 128x8, then CS2 gives another 128x8. This repeats 4 times.

author: benneton
author_rank: Contributor
timestamp: September 29, 2021, 06:40:09 pm
content: I ran additional capture with 20 MHz sample rate and discovered that there is a stable clk data (pin 6).Also, there are 132 rising edges for each side of display. Resolution of the LCD is 264x64. I don't believe chip is actually made for that resolution. At the beginning of each CS1/CS2 there are three CLK rising edges.CS1 [176, 0, 16]CS2 [176, 0, 16]CS1 [177, 0, 16]CS2 [177, 0, 16]CS1 [178, 0, 16]CS2 [178, 0, 16]CS1 [179, 0, 16]CS2 [179, 0, 16]CS1 [180, 0, 16]CS2 [180, 0, 16]CS1 [181, 0, 16]CS2 [181, 0, 16]CS1 [182, 0, 16]CS2 [182, 0, 16]CS1 [183, 0, 16]CS2 [183, 0, 16]So, for each side numbers are coming from 176-183, second rising edge always zero, and third is 16. I wonder if this could mean that 16 is used for offset? And those 0-index list elements maybe some address/command? I have no idea.Anyway, I managed to create code that will be used for MCU for translation purpose (from captured parallel to SPI or I2C).Also, created a decoder for Sigrok and used sdl2 to draw pixels after every CS1/CS2 command.Code for this decoder and also the capture data are available at the github's link: Code and captureStill have no idea which display I can use directly as a replacement. Searched for 5" (or similar size) 264x64 and also 296x64 (due to that 16 offset-lookalike data possibility) - no luck. However, satisfied with the solution that will work with alternative approach with the help of additional cheap MCU as a translator.My answer is partially answered with this. Maybe I will discover something more about the protocol and post it here when I find it. Still cannot compare it with any of datasheets I've found for COG or whole GLCD display solutions.To re-cap, approach was:1.Discover as much as possible about known and often used glcd drivers and controllers2. Use what's discovered to notice patterns or similar techniques that are used to send data to graphical display from a MCU3. Write decoder to make experimenting easier and more fun4.Use SDL2 to draw pixels after each successful decoding

author: benneton
author_rank: Contributor
timestamp: September 30, 2021, 04:04:00 pm
content: Just had an idea that 176 is actually zero if I remove higher 4 bits. So, it goes 0-7. Higher 1011 then would be a flag. Will investigate the datasheet of some of the standard drivers.

author: benneton
author_rank: Contributor
timestamp: October 02, 2021, 05:46:09 pm
content: Potential cogs: SPLC502B, Epson SED1565, ST7567

author: benneton
author_rank: Contributor
timestamp: October 02, 2021, 06:11:14 pm
content: Thanks @MegaVoltMain mistake I made - didn't capture the data with the best possible sample rate. Somehow I assumed that DSLogic is using maximumsample rate. It didn't, so I lacked stable clk signal. Once I got stable clock I discovered it is 132 bytes per page. Also, three clock rising edges for command. 1011 command is used in the chips I mentioned. Those were on the list at the link you've sent. Probably many others are following the same.Main remaining issue is, I cannot find any 264x64 LCDIt seems that those are custom made displays or something.Either I will use 256x64 and trim the output or use two 132x64 displays and accept the middle line.

author: MegaVolt
author_rank: Frequent Contributor
timestamp: October 04, 2021, 09:21:41 am
content: https://aliexpress.ru/item/32817221890.htmlA search for the words "LCD 25664" produces many OLED displays. And a few conventional ones.

author: voltsandjolts
author_rank: Unknown
timestamp: October 04, 2021, 10:12:56 am
content: I like the LCD decoding to produce a display, very nice. I haven't seen that before.

author: benneton
author_rank: Contributor
timestamp: October 04, 2021, 01:37:27 pm
content: @voltsandjolts thanks!You can find very dirty decoder at the github:https://github.com/vladimirdjuricic/dsviewdataJust put the "unknown_lcd" to Sigrok decoders directory.Also, capture data is there.

author: benneton
author_rank: Contributor
timestamp: October 04, 2021, 01:40:41 pm
content: @MegaVolt I guess 264x64 is going to be mission impossible.Those guys did all to prevent after-market solutions.Well, soon there will be some solution with with 256x64 resolution at least. I certainly hope so.

author: Lovkiyslon
author_rank: Newbie
timestamp: July 18, 2023, 07:16:57 am
content: Hi! Did you find a suitable replacement for this display? I am realy need a solutionThank you for any help!