Chipping an HFM ECU ! - Page 2 - PeachParts Mercedes-Benz Forum

Roncallo · #16 10-26-2024, 10:28 AM

Feet first has generally been my approach but being retired and working on my own, I don't have a peer group to discuss these things with. Selecting tools, software and hardware without some sort of support group will be a slow start. Performance Paddock was always my go to place but at you can see it has diminished to a small hand full of people.

I do hear a lot of rummers of what can and cant be done, but until you do it yourself its just internet babble.

Currently I only have my M120 107. Its made with all the parts from a 1996 SL600. It uses dual ME engine ECUs. The transmission is a 722.6. All stock components.

I have been thinking of getting a cheep slave car for experimenting with. Preferably something with an M104 and 722.6 trans before messing with the V12.

duxthe1 · #17 10-28-2024, 01:30 PM

SIince your donor was 96 I'd assume it has an EGS51 trans controller. If it were EGS52, there is a bunch of info online on that module, and would be a great place to start. Otherwise picking up a project car isn't a bad place to start.

In other developments, I picked up another HFM module this weekend. A 93 300E2.8 showed up in the upull yards and I claimed its ECU as soon as I could. I opened it up this morning and much to my surprise it is a completely different ECU from my two others. This one is two boards and has a socketed DIP 28 pin eprom. I'm hopeful that despite the completely different hardware that the binary is similar, though I'm not holding my breath. I'll have time to pull the chip and read it this evening.

Roncallo · #18 10-28-2024, 07:15 PM

Quote:

Originally Posted by duxthe1

SIince your donor was 96 I'd assume it has an EGS51 trans controller. If it were EGS52, there is a bunch of info online on that module, and would be a great place to start. Otherwise picking up a project car isn't a bad place to start.

In other developments, I picked up another HFM module this weekend. A 93 300E2.8 showed up in the upull yards and I claimed its ECU as soon as I could. I opened it up this morning and much to my surprise it is a completely different ECU from my two others. This one is two boards and has a socketed DIP 28 pin eprom. I'm hopeful that despite the completely different hardware that the binary is similar, though I'm not holding my breath. I'll have time to pull the chip and read it this evening.

Of course the EGS52 was used on the 2006 Dodge 6.1 SRT. I have heard it wont work on my V12 but I'm not entirely convinced. Looks like it has the same connectors and plenty of people programing it. The EGS53 was use in 2007 and 2008. For the 96 SL600, the label is EGS K02 of course the V12 uses an oddball. I am finding it amazing all this stuff still works on these 30 year old components.

But with MB parts now becoming scarce, there is more of a need to grow your own or at least be able to repair them.

duxthe1 · #19 10-29-2024, 01:12 AM

Before my 06 sprinter was totaled I was working on the egs52 in it. The binary didn't line up with any of the versions posted online but it was easy enough to compare known files in those and correlate them to mine.

I pulled the eprom from the early HFM this evening. It is marked with a Bosch designation but when googling it, it comes back as a 27C512. The binary in the early HFM is formatted entirely different from the later ones. In a stroke of luck, the table of map addresses is at the very beginning of the file. It was easy to pick out the 16x16 maps from the table and once I defined them in WINOLS they were easily recognizable as the same maps from the later ECUs.

That means it will be quite easy to put the 3.6 fuel and ignition base maps into this early ECU. With a 28 pin DIP eprom swapping the chip is easy. That makes this ECU a good candidate to use as a test mule for playing with the mapping. The one down side is that being a two board module, you have to fold out the boards to access the eprom. The stiff ribbon cable that connects the boards will only tolerate this so many times.

I'm in the middle of comparing and swapping all the C36 maps into the later 2.8 ecu. I'm going to complete that task before defining all the map addresses in this older HFM.

duxthe1 · #20 10-31-2024, 02:26 AM

I finished swapping over the C36 maps into the later 2.8L file, 45 of them to be exact. About 10 maps failed the logical sense test and didnt get swapped. That left close to 100 maps that were the same between the two versions.

I also went ahead and defined all of the map addresses in the early version binary. Completed the task in record time, just a few hours this evening to get 191 map addresses defined in Tuner Pro. After I finished that I had an epiphany about this early version. It is a 28 pin DIP eprom chip in this ECU... and I have an Ostrich eeprom emulator! It is currently still installed in the CIS ECU in my daily driver. Its no biggie to go ahead and burn a chip for that and pull the Ostrich. Since this early ECU already has a socket for the eprom, the Ostrich will plug right in. The emulator will allow me to see where the data is being accessed in the eeprom in real time. This will allow me to see what maps are active and where in the map it is accessing data with a heat map function. It will also allow me to modify the eprom data in real time. Instead of writing and swapping chips, I can load changes with the enter key on the fly. This will be a game changer in terms of figuring out the mapping and its axis data.

Watch this space!

Roncallo · #21 10-31-2024, 09:05 AM

Quote:

Originally Posted by duxthe1

I finished swapping over the C36 maps into the later 2.8L file, 45 of them to be exact. About 10 maps failed the logical sense test and didnt get swapped. That left close to 100 maps that were the same between the two versions.

I also went ahead and defined all of the map addresses in the early version binary. Completed the task in record time, just a few hours this evening to get 191 map addresses defined in Tuner Pro. After I finished that I had an epiphany about this early version. It is a 28 pin DIP eprom chip in this ECU... and I have an Ostrich eeprom emulator! It is currently still installed in the CIS ECU in my daily driver. Its no biggie to go ahead and burn a chip for that and pull the Ostrich. Since this early ECU already has a socket for the eprom, the Ostrich will plug right in. The emulator will allow me to see where the data is being accessed in the eeprom in real time. This will allow me to see what maps are active and where in the map it is accessing data with a heat map function. It will also allow me to modify the eprom data in real time. Instead of writing and swapping chips, I can load changes with the enter key on the fly. This will be a game changer in terms of figuring out the mapping and its axis data.

Watch this space!

Interesting. Is that Ostrich something you can use to find how DAS activated, with the goal of setting it to deactivated permanently. Same question for version coding.

duxthe1 · #22 10-31-2024, 01:32 PM

I haven't dug into DAS in these HFM ECUs but from what I have seen in other modules, security data tends to be located in a small dedicated chip elsewhere on the board and not with the program and mapping in the main eprom. So the Ostrich isnt helpful in that matter.

nulu · #23 11-03-2024, 10:38 AM

I have a complete 95 c36 eng i bought has everthing including engine wiring harness, what should i do to my 94 e320 wagon to get the most out of the 3.6 with minimal wiring swapping, im thinking just use the 36 ecu and use my wiring circuit to starter as i hear the 95 c36 just prevents starter from working via c36 das?

duxthe1 · #24 11-04-2024, 01:44 PM

My experience is that the C36 harness was too short so you'll want to use your 320 harness. You can go ahead and install the 3.6 module and test if it works in the car. If not, plan on remapping the old module for a plug and play solution.

rwd4evr · #25 12-05-2024, 08:48 PM

Wow. Super Interesting and sadly over my head for the most part. I vaguely understand some of this but I'm not very computer language literate. I'm going to start a thread on a 94 c280 Enduro, or "gut and go" race car build. I have a couple simple questions about the ECU with a manual swap . I don't want to hijack your thread but you are definitely the guy to answer my questions.

Sent from my SM-G991U using Tapatalk

duxthe1 · #26 12-05-2024, 09:28 PM

The Enduro build sounds cool, glad to answer any questions I can.

I haven't updated this lately but I have been working on it, progress just seems slow to come by. Foremost I have been wanting to get my emulator working in my early version HFM. So far I haven't had any luck. The ecu doesn't seem to respond at all. I've tried a few things but nothing has worked. I plan to pull my CIS ecu and reinstall it back in to determine if its a problem with the emulator or with the HFM module. I wont be surprised if it is a problem with the emulator since the HFM fires right up with its eprom chip. It is entirely possible though that the Ostrich is ok and there is some valid reason the HFM wont read it that isn't necessarily a bad HFM. I'm thinking maybe something like pull up/down resistors on the data lines that are just out of spec for what will allow it to work. I do fully believe that it can work, that it is possible. Just another puzzle to figure out why it doesn't currently. First thing first, install it back in a previously known working configuration.

Early on I had proclaimed that I had no intention of disassembling the binary to root out this ECUs secrets. Welllllllll..... I have gotten about 1/3 of the way through the 87C196KR microprocessor's 651 page user manual and loaded the binary into IDA PRO to begin the disassembly process. It doesn't do a good job disassembling and I'm wondering if Ghidra is the better choice. One of the main reasons Im going ahead with trying to disassemble is to figure out the checksum. These ECUs have 50 fault codes and #50 is an "ECU internal fault" which I'd bet dollars to donuts sets with a checksum failure. I've ran the engine on a 3.6 map swapped file without checksum correction and it started and seemed to run ok. However I'd like to not set faults and have the program happy in case of unforeseen issues. Disassembly may also help me figure out the map axis scheme, though if I could get the damned emulator working that wouldn't be a high priority.

rwd4evr · #27 12-05-2024, 10:20 PM

Yeah really wish I could help there. Old fashioned k jet I'm pretty good with and simple testing of d jet for resurrections is as far as I go. I think you got it far more under control

Just finished posting mine up if you want a short read.

Sent from my SM-G991U using Tapatalk

oldsinner111 · #28 12-06-2024, 10:12 AM

turbo bandit

duxthe1 · #29 12-10-2024, 10:47 PM

I had a little luck and got the checksum figured out. It sums the entire eprom. That being the case, I don't think it has any relevance on how the program actually runs and is only relevant to making sure they were programmed correctly during production. It seems unlikely that the processor will stop what its doing to add every byte in the eprom just to make sure someone hasn't changed the mapping. My previous guess that checksum inconsistency would set a fault has proven wrong. At this point I'm going to pause the disassembly and try to focus on getting the emulator working.

I've also thought about trying to deconstruct the appropriate CBF or CFF file that Xentry/DAS/HHT uses to define the ECU its communicating with. I have a strong hunch that the map axis identifiers are actually RAM addresses and if I can make enough sense of the CBF/CFF file, it may identify them and possibly their conversion factors as well..

duxthe1 · #30 12-21-2024, 10:56 AM

Breakthough this morning! I figured out how to calculate the checksum. Its a bit of a convoluted process and I have no idea how to write a formula that will correct it automatically. However I can do the substitutions and the following math as individual steps and arrive at a proper checksum value.

I wasn't too worried about correcting it but after getting the vehicle road legal and a week of driving I had duplicated a severe surging under full throttle on occasion. It was reminiscient of when an EZL doesn't see the trans overload protection switch, however I noticed it at just over 3k RPM once which is below the threshold for that to occur, at least with older EZL systems. Not sure if its an issue with my hardware, or possibly a software issue and again possibly an incorrect checksum issue. I put the effort behind it to get it figured out.

The checksum still may not be the cause of the surging issue. I have checked the module coding and the current coding is a US 4speed auto trans, which assuming my wiring is correct on the car, (not yet doublechecked) should be ok. I currently have the ability to read the coding and I am actively working on a setup that will allow me to write the version coding. I want to try coding as a manual trans to make sure the surging isn't related to transmission overload protection.