Engine/Transmission (1998.5 - 2002) Inside the ECU

[Jdonoghue]

Getting ready to build a SCI interface board and try to talk to this thing using the SCI protocol. From what I have found on the internet, and looking at the code, it appears the SCI can communicate using 2 modes: the standard 'ISO9141' protocol (OBD II), and a proprietary protocol. The proprietary protocol is what is used to reflash the ECU. This is probably the 'SCI II' protocol that the Chrysler tools use to communicate, but it doesn't matter, because SCI II is not documented. From disassembly of the code, I can tell what commands I need to send to reflash.



I have built a test setup with the spare ECU. There are switches for +12V, ignition key on, a 'Wait to Start' indicator, potentiometers to simulate APPS, MAP, CTS, IAT, and oil pressure sensors, and a relay board with indicators for VP44 power, Intake Air Heaters, and Lift Pump. This is so I can use the other interesting SCI commands that read the sensors and see how they work. Hopefully I can find some time this weekend to finish the SCI board and do a little programming on the PC to try and talk to it.

 

[Gary - K7GLD]

How about a variable CPS signal to simulate RPM of a running engine?



Jeeze looks like a lot of effort - my hat's off to you - things should REALLY start heating up now!

 

[fest3er]

... As far as copyright violations go, that is an area that may need some exploration/advice. I can do what I want with MY ECM and it's software, as it is a R&D project, and that is even allowed under the DMCA. But, a software company typically needs to place a copyright notice, however small, inside the binary code. If you 'peek' at some Windows files on your PC, you will always see a 'Copyright (c) Microsoft' in there somewhere.



There are NO copyright notices, or ownership notices, in the contents of my ECU's flash or EEPROM memory. The circuit board itself says '(C) 1998 Motorola', but that is a copyright on the circuit board artwork itself and has nothing to do with software. ...

As I understand copyrights, the creator of the work owns the work and all rights to it at the instant it is created. The "Copyright Year, Entity. All Rights Reserved. " notice is really just a clarification that Entity created the work on the year Year, and that Entity has reserved all rights to the work. Copyright law allows certain uses of the Work; without these allowed uses, one could not even read the work (in the case of a book) without violating the law.



So it is fair to peruse the existing code in the ECM to learn what it is doing. And you can even use it, or parts of it, for personal use, but you cannot make your derivative work available to others. You can quote parts of the work in, for instance, a seminar in which you teach others how the Work operates. But if you want to create your own work that does much the same thing, you must make it different enough so that you can easily claim that it is your own work, and not a derivative of the original work.



To put it in in plainer terms, you can use the existing firmware to learn how the engine is controlled. But, in order to make different firmware available to others, you would have to create your own unique firmware, from scratch, that accomplishes the same thing in order to deflect copyright infringement claims. This is what Marco needs to have done with his Mad ECM firmware in order to avoid copyright infringement.



Plagiarism is a form of theft. And, generally speaking, making someone else's work available to 3rd parties (freely or for sale) deprives the creator of economic benefit of his work. It is the same as setting up a music sharing network. While is it always acceptable to play your CDs for friends, it is illegal to give them copies of your CDs, or 'whole' parts of those CDs. It is, however, perfectly acceptable to share excerpts of songs with your friends so that they can hear enough of the song to decide to buy it if they like it.



To look at it differently, suppose you write a song, or write a short story, and your intend to make money from your work. If someone makes copies of your work and gives it, or sells it, to others, that person is depriving you of economic benefit that is rightfully yours. That person is infringing upon your copy rights.



Fair use is fair use. But do strive to stay out of the grey area. And do strive to avoid outright theft.



My intent here was simply to illuminate a couple or three viewpoints, not to admonish or accuse.

 

[Jdonoghue]

Fair use is fair use. But do strive to stay out of the grey area. And do strive to avoid outright theft.



My intent here was simply to illuminate a couple or three viewpoints, not to admonish or accuse.

Of course. I don't ever intend on releasing the firmware, in any way, shape, or form. If anything ever becomes of this, the end user may have to find a way to get their own copy of the ECU firmware to modify. How they go about doing that is up to them. I had to go to great lengths to obtain my firmware - I had to open the ECU up and solder wires to the BDM port, build an adapter, and write software to 'suck' the firmware out of the ECU. I'm sure there are other, less intrusive, ways to obtain it. I do know that you CANNOT read the firmware through the SCI or CAN Bus.

 

[Jdonoghue]

Another interesting idea is that once 100% of the hardware, and communications with the VP44, is known, the original firmware could be 'done away with' and a custom program be written to replace it. If I ever go that route, I'll release the source to the custom program so others can play with it too.

 

[Gary - K7GLD]

Another interesting idea is that once 100% of the hardware, and communications with the VP44, is known, the original firmware could be 'done away with' and a custom program be written to replace it. If I ever go that route, I'll release the source to the custom program so others can play with it too.

I'm sure we all realize how intensely difficult that would be - much like "opening up" a PC, determining how it functions, then using that knowledge to design an Apple type device - a device that performs many of the same functions as the IBM/Intel PC, but with a different hardware/firmware/OS...

 

[Jdonoghue]

How about a variable CPS signal to simulate RPM of a running engine?



Jeeze looks like a lot of effort - my hat's off to you - things should REALLY start heating up now!

I actually had thought of using a PIC or some other microcontroller to simulate crank/cam position sensor signals. If I could find a good used PSG/FPCM module from a VP44, I could actually create an 'engine simulator'. If I wanted to get real fancy, I could use a microcontroller with DAC channels, and even simulate the MAP/IAT, etc. But that would take too much time, and I don't have much to begin with!

 

[V-Metalworx]

The biggest problem right now is that all I have is a disassembly listing of the code. It looks like most of the code was originally written in C. It's not easy stuff, like the Z80 code that I disassembled and changed while working on a large mainframe project (1980's era mainframe). I have a background in microprocessors and electronics, much of this stuff is familiar, but 32-bit code disassembly listings aren't the easiest things in the world to figure out.



Also, I have not yet figured out which inputs go where - if I had a scrap ECM to poke around with, it would be easy to find out things like which analog input pin is the coolant temp. sensor, the APPS, MAP sensor, etc. I only have the ECM off my truck and really don't feel like having to replace it. In the next week or so I am going to have to go hunting for a junkyard ECM.

TRY-E-BAY I've seen some on their if you wait it out you can find a good deal

 

[Jdonoghue]

SCIPod

I've built a small circuit to interface the standard PC serial port to the SCI interface. I'm working on a Linux program to talk to it, right now I can send the '14' command and read the various sensors. There are still a few bugs to work out, but when I have the hardware working 100% I am going to build a cable from it. This cable will become what attaches the laptop computer to the ODBII connector and will ultimately enable me to talk to the ECU in the truck.



The circuit resides on the small circuit board in the upper left of the picture, the one with the LED on it.

 

[Jdonoghue]

Well, I found out that there was no way to get the required 62. 5KBPS from the PC serial port, so I'm going to have to do things the 'hard way'. I have built a new circuit board that connects the SCI interface to the PC, this board has it's own processor and memory and contains a program to convert between the standard PC serial interface and the SCI. I have not done much else, except to investigate some of the interesting functions available through the SCI (please note the numbers are in hexadecimal format):



Function 14: Reads various sensor data. You can read the engine speed, APPS, IAT, MAP, CTS, and oil pressure, along with battery voltage, internal ECU voltages, and a couple of other unidentified items.



Function 13: This initiates some output tests (engine not running). It toggles the following outputs: Intake Air Heater relay 1, Intake Air Heater relay 2, Lift Pump, VP44 Relay, Wait To Start lamp, and an unidentified output. The Intake Air heater test only runs for 5 pulses. The others run much longer.



Example:



Send 14 07 to the SCI. It echoes back '14 07' then a single byte representing the APPS value. (I have a mostly complete list of codes for each input item)



Send 13 28 to the SCI. It echoes back '14 28' and turns the Intake Air Heater relay on/off 5 times.



Now I am working on the protocols for reflashing. Lots of ugly stuff in there, but I now have most of it figured out.

 

[GOT-Torque]

Awesome work so far, very very interesting. What rpm do the timing maps end at in stock form? 3250rpm? Does it appear as though you could "extend" all of the timing maps from the stock limit up to say 4100 rpm?



I would love to be able to monitor all the sensor data via a laptop on the fly (datalogging, etc).



Keep up the great work...

 

[GCroyle]

Wow!

I'm just impressed with your efforts. Looks like your trying to electronically extrapolate its DNA and rework it. My 2 year Associate Electronics Degree is showing it's age reading about your activities. Pictures look like the ECU is in the lab at the head office of the Aliens getting its guts pulled out and explored!



Good luck!!!!

 

[fest3er]

I actually had thought of using a PIC or some other microcontroller to simulate crank/cam position sensor signals. If I could find a good used PSG/FPCM module from a VP44, I could actually create an 'engine simulator'. If I wanted to get real fancy, I could use a microcontroller with DAC channels, and even simulate the MAP/IAT, etc. But that would take too much time, and I don't have much to begin with!

You know, if you were really clever, you might be able to use a parallel port to act as 8 digital I/O lines. Linux should be able to drive a parallel port fast enough; I think they can run effectively at 100KHz. , which should be far faster than you need. USB<->parallel devices should suffice if you need more.



N

 

[Jdonoghue]

Awesome work so far, very very interesting. What rpm do the timing maps end at in stock form? 3250rpm? Does it appear as though you could "extend" all of the timing maps from the stock limit up to say 4100 rpm?



I would love to be able to monitor all the sensor data via a laptop on the fly (datalogging, etc).



Keep up the great work...

Some of the maps I have identified go well past 3500RPM. As for datalogging, you can ALMOST make a cheep circuit board with less than 10 parts to connect a laptop to the OBDII port, and read the sensor data. I have done this but it does not work under Windows, only Linux, because I'm not a windows programmer

 

[Jdonoghue]

Update

Thought I'd give a quick update to this project. Work has had me away from it for quite some time. But the long break from it has allowed me to 'discover' new things as I revisit it.



The very last thing I worked on was the SCI interface and learning the proper commands to erase and reflash the memory. Good thing I have an 'eBay' ECU module to play with! I figured out the protocol for the 'security key' to unlock the programming mode, which allows access to the programming command set. There are commands to erase the flash memory, upload data to write into the flash memory, and the final command used after writing that will 'checksum' the data written and allow the ECU to return to normal operation.



This also means I have erased my 'eBay' ECU. Now I just get the blinky 'Wait to Start', reminding me it's time to return to writing code on the PC to try and reprogram it!



Hopefully I can restore it back to original before summer is here. Once I do that, I can try and load the proper code for my truck (the 'eBay' unit is from an older truck with an automatic trans, I have to make it work on my '01 6-speed).

 

[Gary - K7GLD]

I sure hope you stick with this - never too MUCH info on the electronics in these trucks! I'd *love* to have the ability to do specific monitoring and modification of the ECM from a laptop - these DRB tools are WAYYyyyy too expensive for the common tinkerer!

I would love to be able to monitor all the sensor data via a laptop on the fly (datalogging, etc).

I have a neat Actron hand scanner tool that will do that - pretty neat, and about $175...

 

[Spunkys Ram]

Still keeping an eye on this to see where it leads. So far, looking promising?

 

[Jdonoghue]

More good news

I've done a bit of research and I have found that there is a commercially available USB-to-serial cable that can be set up for the 'weird' baud rates that the SCI requires. And it's readily available from most electronics distributors for about $20. The only other component needed is a cable to adapt the serial pin connector to the OBD connector. This means no special circuit board to make to get a laptop to talk to the truck, it will all be in software.



Once the cable arrives here the real fun can begin!

 

[Jdonoghue]

I sure hope you stick with this - never too MUCH info on the electronics in these trucks! I'd *love* to have the ability to do specific monitoring and modification of the ECM from a laptop - these DRB tools are WAYYyyyy too expensive for the common tinkerer!

Oh, I don't think I'll give up until I figure the whole thing out. Progress may be slow sometimes, but I just don't like not knowing how something works. And I really despise things like proprietary protocols. Reverse engineering stuff is what I do for fun!

 

[JLandry]

Jdonoghue,



What ever happened to the web page you mentioned at the beginning of this thread where you were documenting your work? I tried it today and got a page not found error.



Thanks,



John L.