Creating a Chrysler PCM/ECU Simulator
Chrysler Powertrain Control Modules(PCM) from the mid-1980s through the early 2000s used the proprietary Chrysler Collision Detection(CCD) bus protocol to communicate to other electronic modules in Chrysler vehicles. The CCD bus is a common shared twisted pair communication bus that was gradually phased out for the modern industry standard CAN bus. While tapping into CAN bus to inspect traffic is very easy due to copious public documentation Chrysler’s proprietary CCD bus is only mentioned briefly in factory service manuals.
The problem I needed to solve was being able to swap an aftermarket engine computer into a Jeep Comanche that uses CCD bus. The new engine computer uses CAN bus so none of the existing modules would be able to communicate with it. Until now this meant anyone doing a modern engine swap in a Chrysler with a CCD based gauge cluster would have to replace it a expensive custom gauge setup that generally looked out of place in the dash.
When I started out researching this project in late 2015 I did not have much to go on. I was opening up gauge clusters along with transmission control units to determine the microcontrollers and bus communication chips. However, they were are later chip designs that are branded only with Chrysler information making it impossible to look up information on them as they were entirely proprietary. All I had gleamed at that point was the electrical signalling and termination from the official factory service manuals.
After banging different combination of search terms to burst through Google’s search bubble personalization I manage to come across a Finnish engineer’s web site. Thanks to oh2nlt’s research it pointed me to the datasheet for an older Intersil CDP68HC68S1 chip along with research on CCD bus used on OBD-I vehicles.
What is really interesting about CCD is that it was being developed by Chrysler at the same time as CAN bus by Robert Bosch GmbH in the 1980s. They both use five volt differential voltage signalling and similar termination. However, they are completely different when it comes to protocol.
I do not wish to go in depth here how the electrical signalling works, but Wikipedia has a great resource CAN bus signalling works in regards to dominant and recessive states that applies here to CCD bus. For the actual physical wiring to reduce electrical magnetic interference the two bus wires, high and low, requires one full turn of twist every 44.45 millimeters. A minimum of one terminating 120 ohm resistor is required across the high and low lines. Transmission speed over the bus is 7812.5 baud which comes from dividing the 1MHz clock rate of the CCD controller by 128.
Transmission framing is the same as RS232 8-N-1; eight data bits, no parity, and one stop bit. This is great because it means it will be very easy to implement on an Atmel ARM as a hardware serial or software serial solution.
The packet data format is relatively simple. Message length is variable, but has a fixed length for each packet ID. It consists of an initial byte that is the packet ID of the message followed by a fixed length of bytes that is the payload. The final byte is a checksum for data integrity that consists of the packet ID and payload bytes added together then a bitwise AND is performed against the sum.
Setup and Data Mining
While oh2nlt’s 2003 research was very helpful in kick starting this project the vehicle used in that research was a foreign export OBD-I setup. It is far enough removed from the target application that I had to start from scratch on hardware and software.
- Teensy 3.2
- 2x TI SN65HVD230 3.3 volt CAN transceiver
A Teensy 3.2 was select due to the built in CAN bus controller in the Freescale ARM chip. Using this ARM chip later will simplify the overall hardware footprint of production boards if I ever get to that step. The two 3.3 volt CAN transceivers are being used for both the CAN bus and CCD bus lines. Due to CCD being so similar the CAN transceiver is fault tolerant enough to drive the CCD bus for transmitting only which is fine for testing purposes. Later I will have to switch to 5 volt transceivers as not all vehicle systems are as fault tolerant as the limited selection of hardware on my work table. The SN65HVD230 datasheet on TI’s web site has an excellent overview of using a 3.3v transceiver on a 5v network.
Tapping into the data lines on the Jeep gauge cluster was fairly simple since there are factory service manuals available that detail the connector pin outs. Of course, I still managed to mess that up by hooking the high and low lines backwards end up wasting some time in confusion which I filled writing dry code to get the ARM up and running. After I had found my wiring blunder I also determined that the speedometer in the original gauge cluster I was using was faulty after performing a power-on-self-test on the unit; accomplished by holding down the tripometer reset button while powering it up.
It was time to tweak the test code and start slamming data bytes down the line to excite the needles. The data mining procedure is simple. Loop slowly over all 253 possible packet IDs starting with a one byte message length and keep increasing the message length until every last function on the unit had sprung to life. To save time I only tested message values at a power of two. In the end this took somewhere around eight to sixteen hours over a few days with the gauge cluster in front of me, a piece of cardboard to scribble on, and marathon of movies on the television to keep me occupied. Whenever something would happen on the cluster I would scribble down the gauge functionality that changed and the packet ID range from the log.
What is left?
The prototype code is a messy work in progress and not yet currently available. At the moment it can send the full set of engine related status messages across the CCD bus. It does not support reading messages from the CCD bus and for my project I do not plan on implementing that for now. Basic CAN bus implementation is in work along with communication testing with a Haltech ECU. Ultimately I would like to work the code into a middleware style implementation to support easy I/O multicast across multiple configured buses. The very far future would be a build system to generate he necessary header file to configure buses, vehicle platform, and module support.
Not long after writing the initial draft of this post and publishing my work on various Jeep and Chrysler forums I was contacted by a community member who that found that the Society of Automotive Engineers had an archived copy of the “Chrysler Collision Detection (C²D™) Bus Interface, Integrated Circuit User Manual”. Available at a cost, but this person was kind enough to provide me a free copy. If I had this sooner this initial step of the project would have been much easier.