Reverse engineering an electronic system can be a rewarding yet challenging endeavor. In the February 2015 edition of Circuit Cellar, engineer Fergus Dixon presents four reverse engineering projects and explains how he overcame a variety of challenges.
Dixon details the first project below:
One of my colleagues, who is the biomedical manager at a large hospital, was having issues with hospital gas panels failing and wanted a cheaper repair option. The gas panels were designed and manufactured by a local company that had gone bankrupt several years earlier. After taking a unit away to look it over, I found that the gas panel had a bright green vacuum fluorescent display with connectors for up to 24 inputs. Each input would show whether the gas supply was normal or in alarm, and thanks to some clever design would also show on the display an open or short circuit on the cable to the gas cylinder. There were 0 to 5-V analog inputs. There was a rechargeable 3.6-V battery on each gas panel to save RAM memory on power off (now this is usually done with EEPROM memory). The problem was that the gas panel would lose its memory when the battery failed or dropped below 2 V. Random characters would then appear on the screen, and the system error light would illuminate (see Photo 1).
The suggestion was to look at the microcontroller since this is usually where the memory was stored. The microcontroller was the popular but now obsolete Motorola 6805. A quick glance at the datasheet showed that it had no EEPROM or nonvolatile memory (i.e., memory that is not affected by a power-off cycle). Looking at the chips, one of the eight-pin chips was a Philips PCF8570 I2C memory chip with 256 bytes of memory and there were five of these making up to 1,280 bytes of memory. Since the display had one line of 40 characters and there were 24 alarm inputs each with an alarm message, a start-up message, and a normal operation message, there needed to be at least 26 messages × 40 characters or 1,040 characters, so this had to be where the message data was stored. The battery was the backup for this RAM, so it appeared the memory was battery-backed RAM (BBRAM). The memory voltage supply was held up by the battery, but when the battery failed, it dragged down the voltage supply rail. A quick inspection of the battery terminals showed some fuzziness and fine crystals indicating that it was leaking and was probably not operational any more.
To read the memory required an I2C reader. The easiest way to do this at the time was to make a prototype board using a Atmel ATmega32 and use two pins to drive the SDA and SCL lines. The output data was ported through a RS-232 converter to a computer. I wish I had more research here since I2C reader/writers are very cheap and I did not realize that the Atmel TWI port was actually an I2C port but with a different name due to the Philips trademark. Anyway, I read the datasheets for the I2C interface and made a small circuit which could read and write to one of the I2C memory chips. The I2C interface consists of Start bits, Write bits, Read bits, and Stop bits with the SCL clock line always being driven from the microcontroller but the SDA line being bidirectional (i.e., an input or an output).
After building the prototype and reading and writing to memory, the circuit managed to read and write the whole 1,280 bytes of memory in the gas panel, which was quite easy since the memory chips addresses lines were sequential (i.e., 000 001 010 011 100). The microcontroller was removed from the PLCC socket during this process to prevent any spurious I2C communications. The next part was to read the memory from a working machine since the gas panel I had was now full of corrupted data. After a few trips to the hospital later, I had the memory in a file, and straight away, the alarm messages could be seen as ASCII data. Each message was preceded by one byte which determined whether the gas alarm input was a warning, an alarm or turned off (see Photo 2).
— ADVERTISMENT—
—Advertise Here—Gas panel programmer
The last challenge was the system error light. Even though the gas panel could now be programmed with the correct messages, the system error light remained on. A quick solution was to remove the driving resistor to this light, but then that meant any real system error would be missed. Looking through the gas alarm panel memory again showed that each alarm message had a trailing byte which looked like a checksum. The simplest checksum can be found by adding up all the bytes and this almost worked. Then I realized that the trailing spaces in the alarm messages were also used in the checksum and the game was over. Since then, a lot of gas panels have been able to repaired using the prototype circuit.
The complete article is available in Circuit Cellar 295.
Sponsor this Article
Circuit Cellar's editorial team comprises professional engineers, technical editors, and digital media specialists. You can reach the Editorial Department at editorial@circuitcellar.com, @circuitcellar, and facebook.com/circuitcellar