Engine/Transmission (1998.5 - 2002) Inside the ECU

[JLandry]

I've figured out where the P0602 DTC comes from. Interesting because I have seen reports of programmers generating P0602's. It would be an easy patch to get rid of the P0602.

What?



No detailed explanation on your web page?



John L.

 

[Jdonoghue]

What?



No detailed explanation on your web page?



John L.

I'm not sure I'm ready to let others have at my hard work disassembling the code. Wait until after the whole thing is done, including the PC download cable and the downloader program. Then I'll bust it wide open, 'cause it won't matter anymore!

 

[Jdonoghue]

Site and log updated

I've updated my site and project log, and added a new page to track the RomRaider (ECU Editor). I've gone through the rest of the DTC-generating code, and I'm ready to begin testing downloading of changes into my truck's ECU.



Status updates at Dodge/Cummins ECU

 

[Jdonoghue]

Data logging

Not in the sense of what you'd get with a normal data logger, but I now can run a program on the laptop and have it monitor any memory variables inside the ECU. Fun stuff like the timing and fueling commands going to the vp44, internal load calculation values, etc.



Note that you can't do this with a 'stock' ECU, I had to hack the program to allow me read/write access.



And since I can write, I can modify maps on-the-fly if I wanted to...

 

[BradPatterson]

I don't understand most of this language but this is a very cool read. Congrats on what you've done so far... ... ... ... ... ... . Brad

 

[Jdonoghue]

Getting closer

Memory read/write has been completed. Now that I have the ability to download changes into the ECU, I had better get working on completing the table identification!



I've explained the beginnings of my table-identification process on my web site. Maybe I can figure out how to make some smoke this weekend :-laf

 

[Jdonoghue]

Work continues. I found the map that generates the requested torque from the APPS input and the engine speed. I confirmed this by making some changes to it - I lowered all of the values above 50% throttle (cut it off) and took a drive. The power that used to suddenly appear just before 2000RPM was gone. Just as I had suspected it to be. For fun, I dropped them lower and tried again but it wanted to stall whenever I let out the clutch and tried to go.



At least with the SCI mod, I can just turn the key off for a bit, then back on, and I'm back to stock again.

 

[JLandry]

At least with the SCI mod, I can just turn the key off for a bit, then back on, and I'm back to stock again.

Please explain.



Thanks in advance,



John L.

 

[Jdonoghue]

Please explain.



Thanks in advance,



John L.

I modified the original ECU program, and reflashed my ECU with the modified program. The modified program allows me to read/write memory, even while the engine is running.



I'll try to explain a little bit:



On a normal truck , when you turn the key on, the ECU copies the tables from the flash memory into it's RAM. Then it begins operation. When you turn the truck off, the RAM contents are lost, just like when you turn a PC off.



All of the aftermarket products available now change the contents of the flash (the permanent storage).



The mods I did to my truck's stock ECU program allowed me to hijack two of the SCI commands - and turned them into READ/WRITE commands to the RAM. So, now, when I turn my truck on, everything behaves normally, until I send the commands through the USB cable. Then, I can alter the 'temporary' tables in RAM. These changes are lost when the truck's ignition is switched off.



The idea here is to allow on-the-fly changes to the ECU, to test them out. Once the parameters are where a permanent change would be desired, I can make a flash file out of them, and download to the truck. Then, they would persist, until the next time I wanted to reflash.

 

[JLandry]

Jdonoghue,



I have some random questions I'm wondering about and hope you might know the answers to. BTW, I have no intention of trying to duplicate your work in any way... I'm just curious how this all works.



1. Back in post #84 of this thread, you stated: "I do know that you CANNOT read the firmware through the SCI or CAN Bus. " Just so I understand correctly, you *can* upload new flash files, but you can't download or read them (without hacked ECM software of course)... correct?



2. Can you explain a little bit about the mechanics of how a flash update process works through the SCI interface?



3. When you make changes on the fly to the ECM's RAM memory through the SCI interface, is there any risk data could be read by the ECM at the same you're writing a change? Put another way, what happens if a data is being written to a memory location in the ECM at the exact same time data is being read by the ECM? Can the ECM software "crash"? If yes, what would happen?



4. In looking at the pinouts of the ODBII data port in the service manual, it shows pin 6 as "SCI receive" and pin 7 as "SCI transmit. " It also shows pin 14 as "SCI receive (PCM, DSL)". Does this mean diesel vehicles use a different SCI pin than gasoline vehicles... or does a diesel vehicle use two SCI receive pins?



5. This question may be related to the one above... Do you have any idea on how a Chrysler DRBIII Scan tool is able to communicate with and reflash the PCM? Does it somehow do this through the CCD bus interface provided at the OBDII data port?



Thanks in advance,



John L.

 

[Jdonoghue]

1. Back in post #84 of this thread, you stated: "I do know that you CANNOT read the firmware through the SCI or CAN Bus. " Just so I understand correctly, you *can* upload new flash files, but you can't download or read them (without hacked ECM software of course)... correct?

This is correct. You cannot read out the original flash. I had to physically open mine up and solder wires to read out the program. This was before I found out how/where to download flash updates on the internet.

 

[Jdonoghue]

2. Can you explain a little bit about the mechanics of how a flash update process works through the SCI interface?

Sure. The process works like this:



1. The SCI tool sends a command that causes the ECU to return a 'seed'. This 'seed' is encrypted using a key and algorithm.



2. The result of the seed encryption is sent back to the ECU with another command. The ECU returns success or failure.



3. The next SCI command issued is the command to enter programming mode. The ECU will return an OK status, then switch the SCI baud rate to 62. 5KBPS. It is at this point that the 'Wait to Start' light will begin blinking.



4. Next is the Erase Flash command. This command is sent, followed by a Get Status command. The Get Status command will be reissued until the ECU indicates that the flash has completed the erase process.



At this point, the ECU is erased, except for the bootstrap code. We can begin programming the flash memory, then the EEPROM. Programming is done in blocks. There are three blocks of flash that must be programmed, and one block of EEPROM data.



Each block is programmed using the following process:



1. A Start Block command is sent. This command will contain the starting address of the block to program, and the length.



2. Records are then transferred. I am using 64-byte records, but it may be possible to transfer larger records. As the records are being sent, a checksum word is generated, in the ECU, and in the SCI utility.



3. When all records of the block are transferred, a Checksum command is sent. This command is sent with the checksum word we were generating while we were uploading the records. It must match the checksum word the ECU has. If it does not, there was an error during the data transfer.



After all three flash blocks, and the EEPROM block, have been transferred and checked, a command is sent that causes the ECU to verify and finalize the update process. Immediately after this command is sent, a Get Status command must be sent. If this does not happen correctly, the process will fail.



At this point, the ECU will 'reset' itself. The 'Wait to Start' light (and the grid heaters) will come on for the full duration, as if the engine was cold. Once the WTS light goes out, the process has completed. I usually turn the truck off for a while, then fire it up.

 

[Jdonoghue]

3. When you make changes on the fly to the ECM's RAM memory through the SCI interface, is there any risk data could be read by the ECM at the same you're writing a change? Put another way, what happens if a data is being written to a memory location in the ECM at the exact same time data is being read by the ECM? Can the ECM software "crash"? If yes, what would happen?

I haven't encountered any problems writing while the engine is running. The software is 'single threaded', so if it's busy writing a word to memory, it can't be doing anything else until the write completes. You could probably mess things up by writing to a wrong address, or into the stack area. As long as you're writing to the table area, and you're not writing 'garbage', there should be no problems.



Writing 'bad' data into a table will cause bad things to happen. If, for example, you were to write 'full fuel' values to the torque/fueling table, in the low RPM/load part of the table, you might be able to cause a 'runaway' condition.



You must be very careful when attempting to 'patch' tables while the engine is running.

 

[Jdonoghue]

4. In looking at the pinouts of the ODBII data port in the service manual, it shows pin 6 as "SCI receive" and pin 7 as "SCI transmit. " It also shows pin 14 as "SCI receive (PCM, DSL)". Does this mean diesel vehicles use a different SCI pin than gasoline vehicles... or does a diesel vehicle use two SCI receive pins?



5. This question may be related to the one above... Do you have any idea on how a Chrysler DRBIII Scan tool is able to communicate with and reflash the PCM? Does it somehow do this through the CCD bus interface provided at the OBDII data port?



Thanks in advance,



John L.

Diesels have two SCI Receive pins. The PCM and the ECU share the SCI transmit (Pin 7). It assumes you'd only be talking to one module at a time. SCI Receive Pin 6 goes to the ECU, and Pin 14 to the PCM. I believe a gas engine vehicle uses pins 6 and 7 only, and pin 14 is empty.



I do not know if the DRBIII uses SCI or CCD to reflash the PCM. If I had to guess, I'd say the reflashing is done via SCI.

 

[JLandry]

The software is 'single threaded', so if it's busy writing a word to memory, it can't be doing anything else until the write completes.

As I was reading your response I suddenly realized how dumb my question was! Of course such a simple processor would be single threaded and execute only one task at a time. Commands would have to wait in line to be executed one at a time.

You could probably mess things up by writing to a wrong address, or into the stack area.

I'll bet. Sounds a bit scary!



I wonder if you wrote data to the wrong place you could cause the ECM software to crash and lock-up. While driving I'll bet that could be fun!



Thanks for all the detailed explanations.



John L.

 

[JLandry]

Diesels have two SCI Receive pins. The PCM and the ECU share the SCI transmit (Pin 7). It assumes you'd only be talking to one module at a time. SCI Receive Pin 6 goes to the ECU, and Pin 14 to the PCM. I believe a gas engine vehicle uses pins 6 and 7 only, and pin 14 is empty.

So you're saying you send messages to both the ECM or the PCM on the same line? Or do I have it backwards?



Do commands get transmitted or received with some sort of addressing convention that indicates which device they should go to / come from?



Thanks,



John L.

 

[Jdonoghue]

So you're saying you send messages to both the ECM or the PCM on the same line? Or do I have it backwards?



Do commands get transmitted or received with some sort of addressing convention that indicates which device they should go to / come from?



Thanks,



John L.

Backwards. You Transmit data into the SCI Receive (Pin 6), and Receive data on the SCI Transmit (Pin 7). There is no addressing.



Jim

 

[Jdonoghue]

More stuff

I've described a couple of the maps related to torque generation and torque limit on my ISB RomRaider page: Dodge/Cummins ECU

 

[Jdonoghue]

I had a coupe of the manifold-pressure related maps switched around. Now they make more sense. There is one that is used to adjust timing from the RPM and the manifold pressure. The other is used to limit the fuel rate at low boost.



Interesting stuff.

 

[Jdonoghue]

Smoke!

Looking at code and dissecting/tracing things gets boring after a while. So today, I decided to see if I really was right, and made some changes to the table that appeared to set the limits at certain boost/RPM levels.



It smokes! Oo.



Only for several seconds, until the boost comes up, but there's a cloud left behind for sure. Between this table, and the table that sets the absolute maximum limits, I'm sure I could darken the street at low RPMs if I wanted to.