Origin

I first saw this screen on the ZBD EPOP 900 electronic shelf label (ESL). Thought it is going to be fun just reverse engineer them, so I bought a few of them:

PCB

After I got them, the first thing I tried was powering them up. And... I got nothing. After powering ON, they simply wait for the command to be sent over RF. Without knowing the RF protocol, I am simply unable to tell it to refresh the screen, so I cannot just use a logic analyzer to get the details about how the screen is being driven. I would have to start from scratch.

The PCB is not very complex, it is a small 2-layer PCB, with only one TI CC1110 MCU controlling everything. With some tracing, it is clear how the LCD is connected to the MCU. MCU also has control of the LCD voltage regulation and LCD bias generation. These are important information that will be used later.

MCU

Though I could potentially create my own board or just build a test circuit to drive the screen... but as a first step, I would like to work directly on the original board. So I would need to be able to program the MCU. TI CC1110 has a 8051 core and use the CC 2-wire debugger interface. Unfortunately, I don't have a CC-debugger... but, I have a Raspberry Pi. So with 2 GPIOs I am able to read and write to the internal flash!

I modified the ccprog utility originally targets the Edison to support Raspberry Pi 4, and you can find the modified version of the program here: https://github.com/zephray/cc1110-prog

With the tool it is also to make backup of the original firmware, so I can flash it back if I ever need to.

For compiling the code for it, I am using make + sdcc. It is available in the Raspbian repository. So, I can directly write my program, compile and download it to the board, all on the Raspberry Pi.

Screen

Now, this is the real hard part. There is no Datasheet or specification sheet I can find online for this screen. The board obviously doesn't tell me more other than where the power rail and the data bus are. The original firmware doesn't want to do anything about the screen unless I have a base station.

There is one hope, though. If I can know the driver IC on the screen, by following the IC pin bump, ITO trace, and FPC cable, I can get the full pinout of the screen. The question is how to know that. Well I don't know. But if I can find a IC, that has the right resolution (channel count), and has the right die size, it is very likely be it. By observing the screen and the traces, it is not hard to see that, they are using 2x240 channel column driver, 1x160 channel segment driver, and 1x240 channel segment driver but only using 200 channels. The 240 channel driver measures 7.6mm x 1mm. From the traces I can be sure it is 240 channel driver, not anything higher.

Of all the 240 channel LCD drivers I can find, here is a list of the die sizes:

• S6B0796: 240 ch 16.2mm x 1.1mm
• NT7704: 240 ch 12.9mm x 1.2mm
• NT7702: 240 ch 11.7mm x 1.0mm
• T66H0001A: 240 ch 14.9mm x 1.0mm
• UCi7702: 240ch 10.6mm x 0.9mm
• IST3026: 240ch 13.9mm x 1.1mm
• S1D17A04: 240ch 13.4mm x 1.3mm
• ST8024S: 240ch 8.6mm x 1.0mm
• ST8024: 240ch 11.2mm x 1.2mm
• ST8024T: 240ch: 13.1mm x 0.7mm
• LC4101C: 240ch: 17.2mm x 2.1mm

None of them matches the one on the screen. That hope is gone.

One thing before I go further, the screen likely doesn't have a controller, but rather only have row and column drivers. This is purely based on experience, I have never seen any monochrome screen with more than 1 COG chips that has controller. If it has controller, it would just be 1 chip, doing both controlling and driving. If it doesn't have a controller, means I will not need to send any initialization commands to the screen. This make me confident that I can drive the screen without knowing much about it.

But how? Well I can always just guess. Here are the control signals usually present on a monochrome LCD without controller:

• VSYNC (Also called FLM), means the start of a frame, reset the column driver to select the first line.
• HSYNC (Also called CL1, or LP), asks the segment driver to latch the input (transfer from input shift register to output)
• Clock (Also called CP, CL2 or XCK), just the data clock for the data bus
• M (Also called FR), a signal only present on passive matrix LCDs, defines the polarity of the driver. Toggle this pin would switch the output polarity. Screens are driven in AC by toggling this pin to avoid polarization.
• EN (Also called ~DISPOFF), turn on or off the driver. This is not the Data Enable on the TFT LCDs, this enables the power, not data.

A typical connection diagram should look like this:

So I expect these pins to show up on this ZBD screen as well. Note this ZBD screen actually has 6 pins, so it probably has additional signal or the signal for segment and common are separated.

There are some additional help I can get from the LCD's ribbon cable, by following the trace there I can know which pins are for the segment, and which pins are for the common.

By just looking at the ribbon cable, I get the following list of the pin connection:

• Segment Only Pins
  • P10
  • P17
• Common Only Pins
  • P15
  • P22 (Only one of the common driver)
• Shared Pins
  • P16
  • P21

P1-2 is likely the digital power supply for the screen, because the traces for it are wider, and that line has 2x 100nF capacitor connected.

Just from this list, we can already infer the following:

• P22 is connected to one of the common driver, it must be the FLM/ VSYNC signal.
• XCK must be either P10 or P17.
• LP, M, and DISPOFF are usually shared between two drivers. However I have 4 unconnected signals here. I also only expect 1 pin dedicated to segment and 1 pin dedicated to the common, but I see 2 each here. Means one of the signal is not shared.
• P15 must be that non shared signal, but I don't know which. Similarly, another one is within P10 and P17.
• They likely did that on purpose. I will need to supply the non shared pin with different waveform for COM and SEG.

After hours of trial and error, I get the following:

• Segment Only Pins
  • P10 - XCK
  • P17 - LP_SEG
• Common Only Pins
  • P15 - LP_COM
  • P22 - FLM
• Shared Pins
  • P16 - M
  • P21 - ~DISPOFF

Now on to the timing part. Just like before, start with how standard LCD works.

With a normal STN LCD, the waveform on the control pins should look like this:

So I tried the same thing here, and it works just fine, given you have the correct delay.

The issue left seems to be that the voltage is too high. Back to the PCB, actually I have traced out that there are 2 pins that are being filtered by a 1st order RC filter and connected to the power supply circuit. P1.3 controls the voltage of DCDC output, and P1.4 controls the voltage of bias generation. RC filtering suggests that they are actually PWM signals. Yes, indeed these two pins connects to the TIMER 3 compare output. After setting the voltage lower, I can get a clear image (see the project album).

Source code for the driver so you could reproduce this on your own board:

https://github.com/zephray/zbd-epop-900-screen-demo/blob/master/main.c

Notes

Well it might sound like it was quite easy reverse engineer it, it was not. I wasn't aware that the voltage was controllable (thus not aware that I have the voltage entirely wrong), and I didn't realize that both P15 and P17 are both LP at first, caused lot of confusion at first. At the end I spent lot of time fighting with air. I am glad eventually I have sorted everything out.