Hello everyone,

This is my first post so hopefully I don't butcher it too much. I have a damaged Cummins ECM from a tractor-trailer. I'm trying to get the engine parameters,trip information, etc... off this ECM and transplanted into a new ECM.

I've identified an EEPROM chip and Flash Memory chip on the PCB. This is where it gets odd. I desoldered the EEPROM from the damaged ECM and soldered it to the new ECM. That successfully moved some partial engine parameter data BUT it also erased everything that was stored in the Flash Memory.

So my question,....was there some reason I should have moved both EEPROM and Flash at the same time to avoid this?

Is there some kind of checksum that exists between the two and when mismatched causes the Flash to initialize?

Any help or insight would be great.

Thanks.

 

Any ideas on how or why this might have occurred are greatly appreciated. My understanding of embedded systems and how eeprom and flash interact is in it's infancy.

 

Welcome to AAC!

EEPROM and FLASH are both non-volatile memory, so writing/erasing are explicit operations.

Whether a "mismatched" EEPROM and FLASH device would cause the ECM to do some sort of initialization depends on the system. You should contact the ECM manufacturer for details.

To avoid issues with unwanted writing/erasing, you can tie the WE# pin high.

 

Thank you. Unfortunately the ECM manufacturer is not cooperative to say the least

 

Thank you. Unfortunately the ECM manufacturer is not cooperative to say the least

The situation that you describe is certainly consistent with how embedded systems can be implemented. This is especially true if the manufacturer wants to actively PREVENT users from repairing the device. Contact the Ukranians, apparently they specialize in this sort of thing.

 

That makes sense. Because the ECM is not a so called repairable device. They want it to be replaced anytime there is a problem.

 

Does anyone have any suggested readings where I can learn the different ways EEPROM and Flash could be implemented together? I am wanting to have a better understanding on how/why this occurred.

 

Does anyone have any suggested readings where I can learn the different ways EEPROM and Flash could be implemented together? I am wanting to have a better understanding on how/why this occurred.

I've never seen anything written on this subject. The programmers who implement these methods are under no obligation to share their knowledge and are infinitely creative in detecting tampering and and bricking things beyond recovery.

 

Thats good to hear because I have spent countless hours trying to find information on the subject and have come up with nothing.

Thank you for your responses. This has been by far the most help I have gotten on any forum.

 

Thats good to hear because I have spent countless hours trying to find information on the subject and have come up with nothing.

Thank you for your responses. This has been by far the most help I have gotten on any forum.

You could start backing up data before you try to mix/match devices. If the devices aren't already in sockets, I'd do that if you have clearance. It would make forcing the WE# signal high to prevent the system from doing bad things. Of course, that assumes normal operations are possible with writing disabled.

 

I am going to keep that in mind for future reference. But I believe I have bricked this ECM lol

 

Remember the EEPROM data can generally be written almost a byte at a time whereas Flash has to write a block,

see: http://www.microchip.com/stellent/groups/SiteComm_sg/documents/Training_Tutorials/en532276.pdf

There are wear leveling" algorithms that can be employed to reduce the wear of an EEPROM.
See: http://www.mosaic-industries.com/em...rol/eeprom-lifetime-reliability-wear-leveling

So,e the EEPROM and Flash are likely used together. Just consider the odometer example. It has to be written periodically and say at the end of a trip. What about black box data?

So, the point is, faster changing EEPROM data may not be in a fixed location. The program may be in flash and flash might implement a leveling algorithm and move the fast changing data around.

At the very least, the system has to decide on what happens the "first time". Let's take a simple example where there may be a factory image and a current image and even a previous image. So, the first recovery mode may be revert to the previous image if say a watch dog timer goes off. There also might be a "Jump this pin" and do this and it will revert to the factory image.

Your checksum would be the first indication of a problem where the image would not change places.

The EEProm may indeed hold the image start address of one of 3 images.

Your laptop BIOS is relatively static, but there is a small battery that does the time and it might have some other tidbits of information. But it's static and has very few writes over the lifetime and it doesn't matter if the time is messed up.

The automobile is a different animal. The odometer changes often. Some constants likely get updated after a "driving cycle". They might store the # of times the car was started. The time of the last trip etc.

Do remember that "black boxes" do exist for cars. Info like, "Was the seatbelt fastened at the time of impact".
Likely stuff to be able to re-construct the cars path over some time. So, your storing data all of the time.

 

Can you give me the part number of the ecm? This process is done quite often to remove crash data as the information is placed into a surrogate ecm. What data were you able to retrieve and what is missing. I am assuming this is from an ISX? Correct me if I am wrong.

 

Thank you everyone. I am actually well aware of how the eeprom in a airbag module works just didn't realize the relationship that existed between eeprom and flash in other devices. It is an ISX

 

Sorry if that come off wrong I went back and read it. Did not mean for my last post to sound like that at all haha

 

bwilliams60......the part number for the ECM is 3683289. I was able to retrieve identification data such as VIN, P/N, etc by only moving the EEPROM. But once I powered the ECM up I lost all the previous trip information and diagnostic records. My guess is because it was located in the Flash component

 

I believe you are correct. Has this unit been into a dealership lately or somewhere where an EST has been connected to it? If so, if they were smart enough to create a work order, all that information should have been kept in the work order file. If not, you are probably SOL.
Cummins has a program that they use which is only available to their engineers that can go deep into the ECM and pull whatever data they need, far beyond that of any dealership. They are also able to unbrick an ECM and reset the program with a base program where you would still have to go in and fill in all the parameters. Were the connectors damaged on this unit or was it board damage??? Any pictures?? What were the part numbers of the chips you moved?? I will look further into the chip swap and see if I can help you that way, no promises.

 

No worries I appreciate the insight as Cummins does not offer much help. The board was damaged. This one may be too late but I'll just keep in mind in the future to move both components at the same time!

 

This is an ISM870 ECM, is that correct?
If it any consolation, I have a friend who retrieves crash data for a living and they have had no success with this ECM. I will let you know if I find out any more.

 

Do you mind me asking who your friend is? We can start a private conversation if needed, I just can't figure out how to send a private message if it is possible through the website