Close
0%
0%

Replacing Broken LCD of Weller WD1

Saved from a refuse pile, a Weller WD1 soldering station controller with a broken custom LCD glass. Needed a new display for a new life.

Public Chat
Similar projects worth following
According to postings in the net a common problem with "antique" Weller WD1 soldering station controllers is that the custom LCD display glass loses some or all of its segments. As the original display is not available, a working replacement is needed. A viable fix is to replace the LCD glass with a stock 16x2 character display and the display controller with a microcontroller that emulates the display controller and converts the information in custom LCD glass to the text in the character display. Read here, how that is done.

A Weller WD1 soldering station controller was found in a refuse pile, abandoned apparently because some of the LCD segments had failed. Googling for a fix or spare parts revealed the LCD display isn't anymore available and there were no repair case reports for this problem. For other problems like blown fuse, failed TRIAC, re-flashing the firmware, some. For the LCD problems someone proposed replacing the driver, but in this case, that was not the problem. The driver was fine, the LCD not.

Having some cheap microcontrollers and character matrix LCD modules around, thought replacing the original display with an emulated one might be a viable undertaking.

For the emulated display one needs to choose the point of capturing the input to the display from which on the behavior is emulated. Here the alternatives are before or after the display controller. Of course, one could also connect the display directly to the main controller and rewrite its FW. Can do, but it would likely invalidate the existing user's manuals and overall, be much more involving a project than just replacing the display.

Taking the input to the emulation after the display controller involves much larger number of signals (40: 3 back planes and 37 segment groups) than before it (2: I2C SCL and SDA). The choice is clear.

The display controller is NXP PCF856CHL, an I2C connected chip for driving up to 4 back planes and 40 segment groups. As the data sheet is readily available, no reverse engineering was needed. Just implementing the same I2C protocol as the original chip's was enough. This chip is nice in a way that it is write-only device. That simplified the I2C slave enormously, as responding to reads is more complex than just accepting a stream of writes.

The controller writes blindly segment states in bursts of 2-4 bytes (16-32 segments) every 10-30 ms. Apparently there is a "screen buffer" in the main controller and the segment bits are taken from there with a timer-driven I2C writer process.

The LCD glass is another kind of issue, especially that the one at hand was partially broken. The controller data sheet describes exactly what back-plane - segment group pairs each bit written to it will control. The case for reverse engineering is to figure out the segment group and back-plane assignments.

Activating  a segment group that was still connected to the pin was easy: just connect some static charge to the pin.

For a segment group no longer connected to the pin one needed to reach to hopefully still conducting part of the ITO trace from the pin to the LCD cell.

Activating the whole backplane groups appeared to be not possible. Therefore, repairing of the ITO traces was attempted, with a graphite paste made from graphite dust filed from a pencil core and using rubbing alcohol as the vehicle. No binder was used to make it possible to wash the paste away if needed. (The paste-repaired pins on the top side.) This repair is temporary. The graphite paste will not work for a longer time.

That actually turned out to work quite well. Despite some missed activations and misactivations eventually revealed everything that was needed to draw the map of the LCD glass.

After all needed information was gathered the next step was to choose components and make a replacement strategy. The common character matrix LCD module needs minimum of 6 pins and if one wants to use the RnW signal and read the status instead of writing blindly with long enough timings, 7 pins. I2C needs 2 pins. So it seems a 14-pin microcontroller (power and 12 I/O pins) should suffice. As a short tube of PIC16F18326 microcontrollers in SO-14 variant were at hand, that was natural choice. 16 k instruction FLASH and 2kB RAM should be enough.

The next step was to carve (with a 9 mm snap-off blade knife) the front panel so that the thicker LCD module would fit in the place of the thin LCD glass. Also the module was slightly modified by bending down the bezel holding...

Read more »

wd1lcd.zip

The source code and the HEX file of the firmware of the PIC16F18326 microcontroller that emulates the PCF8576C LCD display controller and converts the information originally shown on the custom LCD glass to corresponding text to a 16x2 character LCD display.

x-zip-compressed - 24.42 kB - 12/21/2022 at 18:06

Download

circuit.pdf

Circuit diagram of the PIC16F18326 microcontroller that emulates the original PCF8576C display controller and converts the information show in the original LCD glass to corresponding information shown in the 16x2 LCD character display.

Adobe Portable Document Format - 19.98 kB - 12/21/2022 at 17:52

Preview
Download

  • 1 × PIC16F18326-I/SL PIC micro controller, 16 kW FLASH 2 kB RAM, I2C and UART used. Less than 4 kW of FLASH in use so other similar PIC16 mmicrocontroller can be used with small modifications to the FW.
  • 1 × GTC-16026 16x2 character LCD display module. Any similar may be used.
  • 1 × Resistor 10 k
  • 1 × 5-pin header for PicKit3

  • About the Firmware

    Lauri Pirttiaho12/25/2022 at 18:43 0 comments

    Tools

    The firmware for PIC16F18326 was developed as an empty project (that is, from scratch) using MPLAB X IDE 6.05 and XC compiler 2.40. The structure of the FW is described below.

    The code

    For the code, see wd1lcd.zip

    Main

    The structure of the main program is typical for an event-loop structured (non RTOS) FW:

    1. initialization of all modules and HW and enabling interrupts (in some sensible order)
    2. The event loop for background handling of non-time-critical tasks.

    This FW basically just receives the commands targeted to the PCF8576C LCD controller via the I2C bus, interprets the segment states to corresponding text to the character matrix LCD module, and sends the text to it. So there is just one interrupt driven process, the I2C receiver.

    There are two other interrupt driven modules in the FW, the serial console and tick. In the production FW the tick is used only to time some functionality of the LCD handling, some delays at the start-up, and the rotation of the menu texts if more than one of them are active (which is never in normal use, but happens in the segment test in the beginning). The serial console was used in the development but is not active in the production FW. But one could use it to take the display data to PC or something. However, commands can't be sent that way. For those the versions having the USB port can be had.

    The configuration words in the main.c were made using the chip configurator in the X IDE but one can write those also from scratch by referring to the relevant headers in the tools. And of course the provided chip specific header was used. It is just so much more convenient not to need to dig the registers and bit locations from the datasheet, like in the old times. The compiler compiles the bit field accesses to single bit sets and gets, just like once done with hand-made assembly.

    The project.h

    This pattern of putting the material needed in all modules, in a small FW project, to one header, I have got to used to while working with Cypress (Infineon) PSoC Creator, but I think I have seen similar practices used even before that. Handy for small projects but may not scale well to large ones, so I don't do that always.

    This header brings in the compiler/device header xc.h and stdint.h, and then defines some project specific handy macros and types, and then includes all module headers.

    The Modules

    The FW consists of seven modules, each described below:

    • sys: The system services 1 ms tick and interrupt server
    • fifo: A simple lock-free FIFO to pass data between interrupt and background processes. This is used by the serial console and the I2C receiver.
    • console: A simple serial two-way FIFO-buffered character interface for test commands and logging. This was used in verifying some functionalities, tracing the I2C data stream, and of course, debugging.
    • lcd: A simple putc/puts interface for writing text to the 16x2 character matrix LCD module.
    • wd1lcdemu: An emulator for the WD1 LCD glass. Give the activation pattern of the segments of the glass, interprets what is being shown and converts them to corresponding texts that are passed to the LCD.
    • pcf8576emu: An emulator that receives the command and data bytes targeted to the PCF8576 LCD controller and interprets them to backplane/segment-group pairs activating segments of the glass, and then passes them to the LCD emulator.
    • i2c: I2C receiver that interprets the I2C writes from the main microcontroller to command and data packets to the PCF8576 emulator.

    The sys module:

    This module implements the 1 ms system tick and the interrupt server. Initialization it disables the analog functions on all pins as all functionality will be digital.

    It also initializes the TMR0 as divide by 8000 to generate 1 ms period TMR0 interrupt. By default this microcontroller starts with 32 MHz internal clock, which is kept as is. The core divides this by 4 as PIC16 is a 4 clocks/instruction design so the peripherals operate at the familiar Fosc/4 rate. Prescaler...

    Read more »

View project log

Enjoy this project?

Share

Discussions

Jan wrote 12/26/2022 at 17:07 point

Fabulous hack! I think I couldn't do such a reverse engineering/hack myself without help, but it's super nice you put that info out there for everyone to enjoy!

Cheers!

  Are you sure? yes | no

Lauri Pirttiaho wrote 12/23/2022 at 18:06 point

Thanks Dan! When tinkering is in the blood, it's hard to resist this kind of challenge. :)

  Are you sure? yes | no

Dan Maloney wrote 12/23/2022 at 17:49 point

Hey Lauri, what a great hack! It would have been so easy to just pitch this station, but your fix is both clever and looks great. Nice job!

I wrote this up for the blog, should publish soon. Thanks for tipping us off!

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates