Raz DC25000 Thoughts and Findings

[TheFlemoid]

Starting a new discussion here because I felt it merited one. About a year about a year ago I made a PCB for the LCD from a Raz DC25000 based on the pin out determined by some logic captures from @ginbot86. I messed with it a bit after that, but didn't put a ton of effort into it since I had work prop up at the time. Last weekend I found that PCB and spent an evening looking into it again and I found a lot of the same failures I did before, but I wanted to document the failures and my opinions on them in case it's useful for any future efforts at reusing this LCD.

I think we all jumped into the Raz DC25000 (and it's offshoots) with the belief that the LCD on the unit would use some variant or clone of the ST7735 LCD driver, which would make a lot of sense because it's common, it's cheap, it supports the resolution (128 x 160px) of the LCD natively, and you can find LCD panels using the ST7735 cheaply, especially when buying at quantity. Tbh my starting goals of this project where "make a PCB where you can easily break out all the lines of the connector, and then throw ST7735 libraries at it and have fun". However, I now don't think this LCD is ST7735 related at all, and I think they actually went through the effort of rewriting their source to support a new display. I'll show why in a second.

I did a write up of my experiences making my PCB in the post linked above, but I wanted to clarify first that I think @ginbot86's pinout work is accurate, and that the 10 pin mezzanine connector that I'm using on my PCB (the connector I pulled off of the vape LCD) is hooked up correctly. With his data I was able to get the backlight to work without issue, and the D/C and reset lines "appear" to be set up properly. But, when I attempt to hook the display up to an ESP-32 running a standard ST7735 display program, it yields garbage on the screen.

In the top of those gifs you see a legitimate ST7735 display (which I bought for comparison) running a basic program on an ESP-32 which (using LCDGFX) resets and initializes the LCD and colors the screen alternating red and green at two second intervals. You can see that the commercial ST7735 screen shows a full white screen during LCD reset/setup and then switches to the red/green pattern. What we saw on the vape LCD was during LCD initialization, instead of a full white screen the vape board shows a "galaxy pattern" of random white pixels that continuously grow more numerous. Then, as soon as the D/C line switches to data, the screen goes completely black. This is the place I left the project in the last time I attempted this a year ago, and I've spent a couple of hours looking at it recently, which caused me to write this post.

A couple of things I've tried:

• It felt weird that we were seeing data (or, rather, that we were seeing pixels change on the display) when the D/C was supposed to be pulled to command mode, so I thought that maybe the input to the D/C pin was inverted. I made a NOT gate out of an N-Channel SI2302 MOSFET to test this theory, and have generally proven that this is not the case. If I NOT the D/C input on the DC25000 vape board, the screen stays white and never does anything. I think that what is happening instead is that the LCD is correctly in command mode during initialization, but it's considering the commands it's receiving over MOSI to be gibberish and thus it's behaving in weird ways. I still can't fight the feeling that a normal SPI display shouldn't be changing "anything" on the screen when set to command mode, so I'm not 100% confident in this assessment, but inverting the line seemed to make the display completely unresponsive which would make since if all the "data" it's receiving is occurring when it thinks it's in command mode.
• I did the same thing with the /RST line, which also caused the display to just continuously show a full white screen, so I think the /RST line is probably correct.
• I lowered the frequency of the SPI bus down to 5Mhz, thinking maybe my PCB routing was crappy and I was getting crosstalk with that high freq, but this didn't seem to have any effect.
• Thinking that maybe it's not the ST7735, but is another common LCD driver and they're just using the driver with a non-standard resolution (like they were with the ST7735 on the Raz DC9000), I also tried driving the display as an ST7789, ILI9341, and ILI9163, all with the same results (funky white pixel pattern when in command mode, black screen in data mode).

Not sure what else to do, I spent a few hours googling, to see if anything had been posted in the year that I hadn't looked into this. Turns out, something (maybe, take a grain of salt here guys) had. This guy said he was able to get the p/n for the display itself.. Now I say take a grain of salt cause I tore apart one of my displays and I didn't see a part number anywhere under any light conditions. But he says he did and that it is a CT018TN01. Assuming that's true I went ahead and looked up that part number and found this display by Innolux . I'm not 100% convinced that this is the right display (the datasheet says this thing was first made in 2003? I don't remember this kind of display being prevalent back then, but maybe it's an old manufacturing line), but the specs do mostly match from the datasheet (1.79 inch diagonal size, 128x160px resolution). The datasheet for this one says that the gate/source driver is a Himax HX8609A and HX8302A. I went and looked those up, and found these two datasheets. I'm a little past my knowledge base here, but it looks like these chips work in parallel, with one being the actual gate driver and the other one functionally being VRAM?

Again, I am a little past my experience base here, so it could very well be that I'm going down the wrong rabbit hole and that the problems that I'm running into are due to my design (and the post about discovering the LCD type is incorrect), but it seemed to make a lot of sense to me that I'd be seeing gibberish if it's a different controller then expected and if the initialization sequence was just completely wrong. What doesn't make sense to me is seeing random pixels populate on the screen when the display is supposed to be in command mode, but I thought this may also explainable if I'm just sending it the wrong instructions entirely.

Anyone have any thoughts on this? And, if anyone has tried to reuse this display, are y'all seeing the same results?

[TheFlemoid]

Posting a follow up for posterity, the riddle has been solved! @ivan2348 figured out in a continuation of this closed issue that the LCD is indeed not an ST7735, but is instead a GC9107. Most hobbyist GC9107 displays are 128x128px, but the actual addressable RAM in the LCD controller supports 128x160px, and this display just takes full advantage of the VRAM. He also noticed that the LCD is using a couple commands that either aren't in the datasheet, or are in the extended instruction part of the datasheet and aren't typically used in hobbyist GC9107 libraries (not that there are a lot of those out there anyway). His controller for the display can be found here. This is designed for ESP32, programmed with the Arduino IDE via the Arduino ESP32 core. Setting up a dev environment with an ESP32 and that IDE, I was able to get his example working in about five minutes.