reverse engineering wire protocol

Question

I have a home appliance consisting of 3 main items:

1. interface board (display + touch buttons)
2. control board
3. actuators

A few more findings about the appliance:

1. Interface board and control board are connected with 3 wires labelled as GND, 5V and BUS.
2. The interface board is not overly complicated from functional perspective: a couple of segment displays, a few LEDs, buzzer, a number of touch buttons. The point is that the requirements for interface speed are not high.
3. At this point the names "interface board" and "control board" are a guess based on what I think might be their functions. My assumption at this point is that the interface board send keypress events to the control board which in turn sends what should be displayed/beeped.
4. I identified that the control board main chip is r8c/27 CPU.
5. I am interested to not only read, but also modify the communication between interface and control board.

Now the question: how would you approach identifying and emulating the protocol without spending a fortune? Are there any cheap hardware platforms that would help me with that? Maybe even some standard setup for arduino?

The best thing that come to mind right now is that I could buy a cheap oscilloscope, but while it could help me understand the protocol, it would not help sending the signals to verify the understanding.

Are there any standard protocols that would match this setup besides 1-Wire?

Answer 1

Assuming the chip that's connected to the 3 wire on the 'interface' board is another MCU then you will have to discover the protocol.

Aside from one-wire, CAN will work with one wire. There may be others.

Sigrok/Pulseview with a '24MHz' logic analyzer can decode those two and many others (edit: such as LIN). Total cost is less than $10.

Then you would know how to set up your Arduino to generate the commands and supply any required responses. There are libraries for one-wire.

I have not detailed what to do if the circuit lacks galvanic isolation from the mains, but if that is the situation you'll need to provide isolation (typically via an isolation transformer on the power supply) or any equipment you connect to it, such as computers, oscilloscopes, logic analyzers etc. can be damaged permanently and may be uneconomical to repair. It's also possible to get a serious or fatal shock or damage your eyes from vaporizing metal.

Answer 2

If you don't know anything about the protocol, then get an oscilloscope to figure out of the protocol is analog or digital, and to figure out the voltages and waveforms used on the wire.

It helps to see the protocol in bit level too, might help see how a logic bit is sent on wire, i.e. line coding of pulse width or manchester or whatever, or no coding at all but simply using half duplex UART protocol. And also to get some grasp on the bit rate.

If the protocol looks digital and has compatible amplitude with a 5V or 3.3V digital logic, then you can connect it and analyze it with any MCU or cheap logic analyzer.

It can also help to reverse-engineer the schematics how the wire connects to the MCU, i.e. directly or through some kind of transceiver circuitry, so you can build a mathcing physical interface.

Answer 3

Start by looking at the bus with an oscilloscope. You'll know what signal levels there are, what is the approximate bitrate, and so on. That will tell you what sort of data acquisition setup may be needed - sample rate, analog vs. digital, etc.

Then you'll want to capture various messages the IF and CTL boards send between each other. You can keep using a digital oscilloscope for this, although it may be a bit tedious.

Most digital oscilloscopes today have long enough capture memory that they can record fairly long serial sequences, as long as the sample rate is set to say 8x the bitrate. The idea is to sample as slow as reasonably possible - just enough to capture decodable data.

You can then transfer the capture from the oscilloscope to the PC, and use a Python script to try decoding the data.

Instead of an oscilloscope, you could use a logic analyzer. A cheap one like those ubiquitous 24MHz/8ch ones should be enough. If you want to get an excellent professional-grade analyzer, then I can recommend Saelae products. Their UI is as responsive as a video game. Butter smooth. Just the software is worth the price of the product. The analyzer runs at maximum sampling rate at all times - it captures each edge at maximum timing fidelity and then transfers the timestamp of each edge found to the PC. As the edges get very dense, it automatically adjusts the representation of the data to get best use of USB bandwidth available.

Answer 4

If I had no testing equipment (oscilloscope, etc), I would begin by exploring the "interface" board, the one with buttons and/or display. What ICs (integrated circuits) are on it? How many buttons does it use? Is there a separate driver IC for the display?

Even though I do have an oscilloscope, this is still my first method. It is a common practice in appliance design to divide the boards functionally, with one containing the main controller and another the input and display "human interface" circuitry. This way, the interface components (buttons etc) are operated on low voltage, which is safer than mains voltage in case the button covers would be broken.

Here is a typical example of such a board from my field of practice: It is the interface board from a washing machine. Various brands and models use this exact board layout, varying only in the main IC (TM1628 x ). You can see here at a glance the components:

1. Buttons (the black square components on the lower side if this picture labeled "SW n" in white letters on this board.
2. Indicator LEDs (above some of the buttons, small light-colored components arranged in grids, labeled "LED n" on this board.
3. A numerical two digit, 7 segment, LED display.
4. Lots of jumper resistors (small black components that say "0" on them--these are just "bridges" for one lead to cross another without contact between them.
5. The main control IC (the large black rectangular component on the right side of this picture, with lots of pins).
6. The connection header is found at both ends of this model, with similar labels to the one you mention, plus a few: +5V, GND, STB, CLK, DIO_1

The IC is the only digitally active component (edit: the 7 segment display also uses digital inputs); there are a few capacitors and so on, and the resistors are as near inert as economically possible.

Here is a close up of the IC:

It has varnish over it, which you can sometimes carefully scrap away, or wash away with a bit of isopropylic alcohol on a cotton swab, to see the label.

The "interface" board's main driver chip is the interesting one: it is likely to define the sort of interface, since the main "controller board" often has a more general-purpose micro-controller with software written to interface with the driver chip. This one is a TM1628.

With this label, I look for the datasheet, which begins with:

DESCRIPTION TM1628 is an LED Controller driven on a 1/7 to 1/8 duty factor. Eleven segment output lines, six grid output lines, 1 segment/grid output lines, one display memory, control circuit, keyscan circuit are all incorporated into a single chip to build a highly reliable peripheral devicefor a single chip microcomputer. Serial data is fed to TM1628 via a three-line serial interface. Housed in a 28-pin SOPackage, TM1628 pin assignments and application circuit are optimized for easy PCB layout and cost saving advantages.

The rest of the datasheet is dedicated to a detailed description of the serial protocol, commands, and function of the IC, which is exactly what you need to decode and/or emulate and inject commands.

The particular serial protocol used in this chip seems to be a variant of SPI (see the "bit-banging" section of this Wikipedia article), with voltage (+5V in the picture), ground (GND), data (DIO_1), clock (CLK) and strobe (STB) lines. However, some SPI protocols can be used without strobe and clock lines.

Another protocol that is often used in home appliances is I2C, but this uses two lines: clock and data.

Answer 5

tl; dr: Electrolux and other (especially European) manufacturers use a protocol called LIN, or Local Interconnect Network. It uses one wire in half-duplex and is based on UART at about 19.2kbps. It's also known as ISO 17987, used in automotive and controls (including appliances.)

Now the question: how would you approach identifying and emulating the protocol without spending a fortune?

Look at the microcontroller datasheet: it has a LIN peripheral. Also, with the information provided in the comments that it is an Electrolux cooktop, I confirmed it indeed uses LIN.

Are there any cheap hardware platforms that would help me with that? Maybe even some standard setup for arduino?

There are LIN projects in Arduino-land, so yes. Microchip, ST, TI, Renesas and others have deep support for LIN.

The best thing that come to mind right now is that I could buy a cheap oscilloscope, but while it could help me understand the protocol, it would not help sending the signals to verify the understanding.

If you didn't have other information and went at it 'cold', the scope would give you kind of an idea - the higher voltage would tell you it's not 1-wire for example.

But to fully reverse-engineer not just the protocol, but its higher-level states, you need something that does protocol analysis. This implies that you know what protocol is in use and you can get a decoder / analyzer module for it.

But lucky for you, we know that it's LIN, and knowing is half the battle. At any rate the Picoscope has a LIN plugin, so that would be a reasonable choice.

An alternative is a LIN analyzer. Microchip offers one that is a little more economical than a Picoscope.

Are there any standard protocols that would match this setup besides 1-Wire?

We established that LIN uses one wire. One thing that differentiates it from 1-Wire is that LIN is specified to operate at the 'battery voltage' of the system, which in a car will be 12V or so, same as CAN bus. In contrast 1-wire is typically 3.3V logic-level voltage.

Further Reading

More about Renesas' LIN implementation

A TI LIN appnote

LIN Wiki page

And... there's substantial LIN work in Arduino-land with many active projects. Try a search for 'Arduino LIN'.