Reversing engineering serial protocol

[reubeno]

Hi, I'm looking for some guidance trying to reverse engineer a serial protocol between a handheld programmer and a radio (circa late 1990s).

Both devices have a 80C31 micro controllers in them, clocked at 12Mhz. I've hooked up the TX/RX lines to a PC based logic analyser but I'm struggling to determine the correct format. The TX/RX lines looked to be connected to the 80C31s internal UARTs, so I'm assuming this is a standard serial port and not a proprietary protocol. I tried decoding at 57600, but I'm seeing Frame Errors and the bytes don't seem to quite be aligned. Adjusting the baud rate to a very odd 77500 resolves some of the frame errors, but I'm not sure how to determine if there are 8/9 data bits, if parity is enabled, the number of stop bits. I've no idea what's data is going over the serial port, so I have nothing to cross reference to. I want to make sure what I'm decoding is correct before starting to try and analyse the contents of the frames.

See attached a trace, with two frames (decoded at 57600).

Any pointers would be appreciated.

[ebclr]

You challenge need 2 tools

One of those

https://sigrok.org/wiki/Supported_hardware#Logic_analyzers

and this software

https://sigrok.org/wiki/Downloads

This video can show you wht's all about

[hexreader]

You need to accurately measure the time of the shortest pulse to find bit time, and take the reciprocal to get baud rate. Looks like somewhere around 250k baud to me, so maybe 230400 baud if it is a standard value.

The other problem is that you need to tell your software to decode "idle low" signal. It seems to be expecting "idle high" signals judging by the given trace.

You need to increase sampling rate for accurate signal timing.

[reubeno]

Thanks for the pointers, especially regarding the inverted signal, I had missed that. I resampled the signal at a much higher sample rate as well as measuring the spacing of the shortest pulses on the scope (at 5.5uS) but the bits still don't line up, as I'd expect. I'm starting to think that this is a custom protocol. I know that there used to be a custom PC ISA card interface for this equipment, it didn't run off a PC's serial port. The next step will be to try and disassemble the firmware and / or find a 8031 simulator to see how the UART control registers are being programmed.

[reubeno]

To close this out for now, with a bit of disassembly of the firmware, it looks like the 8031 is using the UART in multiprocessor communication mode, which supports multiple devices on a common bus and a 9-bit UART. In this mode, a device address and data byte are sent one after the other. I think I've managed to confirm the baud rate as well, as "Oscillator / 64" based on the control registers, which is 187,500, which corresponds to the 5.5uS I was seeing on the scope. Now to try and actually decode what's going over the bus.

[reubeno]

Thank you for some of the pointers early on with this project. I've just about got everything working now and wanted to share the approach I took, as a number of the ideas came from EEVBlog & mikeselectricstuff videos.

1) Photographing both sides of a board and then mirroring one image before printing it out, made tracing the physical hardware (only double sided boards) of the device I wanted to emulate much easier. I had some schematics for the hardware I was working with, but the board was a different version to the schematic.

2) In order to decipher the firmware, I disassembled the ROM. I found the data blocks for the messages that could be displayed on the LCD screen and was quickly able to tie these back to the code segments that used them, which helped narrow down the areas I needed to investigate further. That said, it was taking a while to decipher some parts of the code, so I wrote an emulator for the 8051, that allowed me to stub out sections of code e.g. writing to the LCD (where I'd just print out the contents of the screen memory). I did find a few emulators on the web, but none of them were flexible enough. Its only an 8-bit micro so didn't take long to write and I only implemented about 200 of the 256 op codes as the others weren't used. This was good enough in helping me understand the higher level communications protocol.

3) The above disassembly also revealed that the bus was operating at 375k baud, using a 9-bit word, as the device uses the 8051 interprocessor communications mode, which is documented in a few places (e.g. http://www.idc-online.com/technical_references/pdfs/electronic_engineering/Serial_Port_Control_Register_SCON_Of_8051_8031_Microcontroller.pdf).

4) I used a DSLogic pro (http://www.dreamsourcelab.com/order.html) to capture activity on the bus. There were however messages on the bus unrelated to the device I wanted to emulate and I found that the bus was being driven through a transistor and putting the logic probe on the base of the transistor enabled me to see just the activity from the device under test, filtering out all the other traffic which was very helpful. The software for the DSLogic pro has some limitations and I found a few minor bugs, but overall it worked very well.

5) I used a 8051-Ready development board (https://shop.mikroe.com/ready-8051-ready) to prototype the first version of my hardware. The 8051 only has a single UART, so with this talking to the bus, I added a parallel interface to an Arduino Uno and used its UART to interface to a PC. A single chip solution would have been nice and I know someone that is working on a similar setup using a PIC16 and a software UART. Whilst its a two micro controller solution, it eliminated potential problems as the hardware interfacing to the bus, is the same as the original manufacturers.

6) Chris Gammell's videos on Kicad were invaluable and I made the switch from a paid version of Eagle (subscription - no thanks!). I hit a few issues along the way, for example some of the pads for the PLC44 socket are miss numbered and duplicated. A big thank you to Chris for his videos.

7) Following the discussions on this forum regarding AllPCB and PCBWay I ordered version 1 of my board from PCBWay. I went for the 24 hour service and the boards turned up in the UK within a week. However, by the time postage had been added, I went over the £39 limit and was charged import duty and VAT. According to DHL, the cost of the postage is included in determining the value, so that added another £19 (ouch!). For the second revision of the board (to fix a couple of minor errors) I went with AllPCB and with the free postage, the order total came to $5.49 which was unbelievable and there were no additional charges. They also threw in a few extra boards for free. So all in, the AllPCB boards were about 10x cheaper. This special offer of free postage from AllPCB can't be sustainable long term though, so get in quick if you want to try them out. As for the quality, both AllPCB and PCBWay boards looked very good, the web ordering process was seamless and I didn't have any issues uploading the Gerbers from Kicad.

The final version of the board is below and the hardware is working just fine, now to finish off the software.

A big thank you to all those that are active on the forums and of course Dave, Mike and Chris for the excellent videos.