Chipping an HFM ECU ! - PeachParts Mercedes-Benz Forum

duxthe1 · #1 08-24-2024, 04:01 PM

As an extension of my JDM AMG CE project I am embarking on the journey to "chip" an HFM ECU. I feel it deserves its own thread, so here we are!

A bit of backstory for those thus unfamiliar. I started a project car, a 1993 320CE, Japanese delivered, into which I have swapped the drivetrain from a 1996 C36. The C36 is a DAS car and needs drive authorization so just swapping over the HFM isnt a solution. Hence my need to get the 3.6 mapping into an earlier non-DAS ECU. I currently have the 3.6CE running with a 1994 E320 ECU. It fires right up and runs ok but I know it isn't reaching the 3.6's potential.

The module I'm going to chip is from the 1993 300E 2.8 donor car that has already donated a lot to the project. Comparing it with the C36 ECU they are virtually identical in layout excepting the C36 ECU has one larger SMT mosfet and its associated smt resistor where the 2.8 ECU only has the unpopulated pads.

The first step is figuring out where the mapping resides. None of the chips on the 3.6 ECU have a number that comes back as a eprom but thankfully the 2.8 ECU has a chip marked M27C1024. This comes back as a one time programmable eprom. The fact that this specific chip has a sticker with a numerical designation in each ECU was also a good indication that it contains the application specific info. Lastly exhaustive internet sleuthing turned up a hint, while not that specific chip #, that the eprom would be in the plcc44 package. With this figured out I'm confident to begin this project.

I have ordered the adapter that will allow my Wilhelm eprom reader/writer to interface with a plcc44 package chip. I have ordered plcc44 sockets since I do not intend to solder the chips back in place. I will install a socket on the board to allow easy swapping of chips. Lastly I have ordered in a handfull of M28F102 chips which should be a reprogrammable drop in replacement for the M27C1024.

My first step will be to pull the eprom from both ECUs. Removal should be straight forward with a hot air station. There is a lot of room around the chip so no big worry about damaging nearby components.

duxthe1 · #2 08-30-2024, 08:06 PM

I've begun the actual work on this project. Here's a few pics along the way. I prep the board for chip removal by wrapping it up pretty well in aluminum foil leaving only the chip exposed. Added a bit of flux and hit it with the hot air. Within about a minute of the hot air, the chip is free. A bit of touch up with the soldering iron and solder wick and the board is ready for mounting the socket and the chips are ready to read.

duxthe1 · #3 09-02-2024, 02:23 PM

My adapter came in and I was able to read both eproms. The C36 chip was a bit finicky and I had to try reading it as several different versions of the chip before I landed on one that would verify the read. With both both chips read it was time to dive into the mapping.

The first map I located was a big 16x32 that I think is the air mass transfer function. This map is in the 2.8L file but is not in the C36 file. I beat my head against this until I concluded that the C36 has several large 2D graphs in the same location and what I suspect happens is the C36 computes this from two 2D maps (air temp and sensor voltage) instead of looking it up from a 3D map.

The next map that I found that looks familiar is what I believe to be the fuel map. This same map shows up in the C36 file. Its not in the exact same location but its within a few dozen bytes. The maps, while very similar, are also not exactly the same with the C36 file having slightly higher values which further supports the idea that this is the fuel map.

Another map of importance I wanted to find is the ignition map. There are a few different maps that I located, but of the group one looks more like an ignition map than others. Like the fuel map, these maps are close to the same location in both files but the C36 map certainly looks more aggressive. I don't have any factors or offsets to define the axis or the data but dividing by 1000 gives plausible values for the whole map.

There are quite a few other maps that are easy to spot in the files. I'll likely spend some time cataloging them to swap them into my "tuned file" without actually knowing what they are. If the data is different but similar enough to pass a sanity check then it should probably swap over. There are bound to be maps for things like accel enrichment and cold start enrichments that I would not be able to recognize. I think the best approach is to try to get them all.

cth350 · #4 09-02-2024, 11:20 PM

how does the disassembly of this chip compare the the one you did last year? -CTH

duxthe1 · #5 09-03-2024, 12:55 PM

This one is a lot easier than the CIS ecu, for two reasons. First I've tuned a standalone EFI before so I'm familiar enough with a fuel and ignition map to be able to pick them out of a lineup. The CIS ecu doesn't have either of those easily recognized maps. Secondly the CIS was the first I tried to dissect so I was in the lower corner of that learning curve. In the meanwhile I've also dissected an EGS 52 trans module and an EDC16 CDI module so the HFM isn't really that big of a deal.

cth350 · #6 09-03-2024, 11:27 PM

I was thinking from a coder's perspective that the same basic runtime is used by both controllers, presuming the same vendor (bosch, becker, etc?) developed the ECUs.
-CTH

duxthe1 · #7 09-04-2024, 09:44 PM

Its really apples and oranges. The CIS is 8 bit and the HFM is 16 bit. The CIS generates a positive or negative control current for the EHA where the HFM fires the injectors and coils. In the CIS eprom dump there is a block of data that is the start address for most of the maps. Once I figured that out I was able to define almost all of the maps though I only worked out what a handful of them actually are. I haven't found anything like that in the HFM.

Unrelated... I kept trying to reconcile the difference between the 2.8 air mass transfer function map and what I was getting in the C36 file. Eventually I decided to re-read the chip since it was reluctant to read to begin with. Depending on which version of the chip I attempted to read it as, I would get differing data!!! that would verify!!! I read it several more times as differing versions until I landed on a consensus. When looking at this "consensus file" the air mass transfer function map was the exact same as the 2.8 map.

duxthe1 · #8 09-10-2024, 01:32 AM

After a long weekend of camping and fishing I spent a bit going over the file this evening and dug out the map addresses. I was trying to see if I could figure out the axis data for some of the maps I had already defined. I did a search for the map location "9900" with a few random hits when I realized I needed to search 9900 as a hex value and not a decimal value. It turned up in a large map I had defined but hadn't made any sense of. As hex data I recognized this map wasn't a map, but map location data with each value indicating the start address of a new map. 186 of them to be exact!

I've got some tedious work ahead.

duxthe1 · #9 09-12-2024, 12:03 AM

Another revelation and another confusion... The first part of the block of addresses are not actually maps, they are axis descriptor data for the maps. This data is in 8 bit format which became obvious when one of the addresses would have split a 16 bit data point. Once I swapped the view to 8 bit, the data in the address locations all followed the same format and was either 8 point axis or 16 point axis data. This is great because I was looking for the axis data. I don't need this to just swap maps over but if I want to modify any maps it gets imperative to know where in the map you want to make changes.

While this is great progress, it digs the hole deeper too. All of this axis data appears to be at the beginning of the block of addresses and the actual maps are quite a bit further down in this block. I have yet to discern any way to assign any of the axis data to any of the maps. Other ECUs commonly have this data right in front of each map, easy peesy. There are some small blocks of data after the maps that I have yet to dig into, hopefully there's something in there that helps.

duxthe1 · #10 09-16-2024, 09:29 PM

The axis data has been giving me fits. The very first address in the list looks very good as RPM for the 16 values. If you apply the common 8 bit RPM factor of *25 (multiplied by 25), it seems unlikely that this could be anything else. See the pic and note the vertical axis. The fit is perfect.

The data in these addresses follows this format:
header value---00---data length---data---00

In the case of the aforementioned first address:
151 00 16 24 30 40 50 60 70 80 100 120 140 160 180 200 220 240 255 00

It is these header values, 151 in this case, that has been perplexing me. The first 8 addresses in the list all use this header value. There are also a handful of other header values,168, 169, 170, 172, 173 with varying number of occurrences. The data length is almost always 8 or 16 but every deviation I've seen so far has correctly described the amount of data following.

The brain exploding part of this is that before the list of addresses, there is a block of data that uses the format above, all using these same few header values, but whose data can not logically be a map axis. (IE a string of ascending numbers but half of them are the same value) Presumably they are 2D maps.

The last mind blowing thing of note is that in the C36 module, these header values are all 4 higher than in the 2.8 module. All of the 151 header values are 155, and so forth. In the case of the first address, the header is different but the data that forms the axis is the same.

I have a 3.2 module, but it is currently running the car so once I confirm I didn't FUBAR my modded module I'll pull its chip and read it. Maybe the 3rd data set will help shed some light on it

At this point, it would likely take pulling the op code from the processor and disassembling it to try to understand what is actually happening with this data. I'm not motivated to go that far. I can copy maps without understanding any of this. I can also tweak maps without exact axis data. I'll ask around some ecu tuning forums and see if I can get lucky though.

duxthe1 · #11 10-23-2024, 10:38 PM

Its been a bit since I updated this project. A coworker recently bought a 05 E320 CDI and I offered to tune it for him. So I pulled its binary, set about finding all of the relevant maps, created an XDF for it in Tuner Pro, and created a decent stage 1 tune (all stock parts). It has taken a fair bit of time so I back burnered the HFM project.

With the CDI tuned, I started working on the HFM again without really making any significant progress. I went ahead and entered every map in the table of map addresses into Tuner Pro. Tedious to say the least. I spent a fair amount of effort researching common motronic factors and offsets to apply to the axis data in an attempt to make sense of them. Not much luck on that front. Most motronic ECUs use 40 as the RPM factor so I decided to apply that to each 16 byte axis to see if one made any logical sense. Lo and behold one of the five axis did. Axis descriptor "AD" (173 decimal) is the only one that has plausible values as RPM. So I'm calling it. AD is RPM! It's a small victory but it is progress.

There are 4 remaining axis that are 16 bytes. Certainly one of them is load, and I'm confident another will be coolant temp. The remaining 2, I'm not too sure about.

Roncallo · #12 10-24-2024, 10:34 AM

Interesting project. I will be following this one. Two questions

1) It seams you are able to get into the bowels of the ECU and you goal is strictly to bypass DAS. Are you unable to get to the DAS code and just turn it off?

2) On my 96 M120 it also used DAS but the first iteration (Non Transponder type), I was able to start the car to disarm DAS than disconnect a few wires that went to the DAS module so it could never be armed again. Don't know if that can be done with the later transponder versions but I assumed I could just place the transponder ring and key under the dash and that may work. Are either of those options possible for you?

duxthe1 · #13 10-24-2024, 02:36 PM

I wouldn't say Das is strictly why I'm pursuing this project. Sure, if my donor car ECU would have been plug and play I wouldn't be here, but I also want to be able to tune the ECU. Word on the street is that the 3.6 can be tuned to just shy of 300hp and well, if I'm gonna be futzing around in an ECU, I'm gonna be looking for that 10-15 hp.

Since my project CE is a 93 it is a non DAS car. I could have wired in the DAS system but I'm endeavoring for it to be as close to how MB would have built it as possible. Additionally DAS parts are becoming more and more unavailable, so I didn't want to engineer in an obsolescence problem in the future.

An admittedly small amount of research implies that its pretty impossible to code out DAS. The common solution is an emulator. Earlier non DAS ecu mapped to run the 3.6 just seems like the much cleaner, simpler solution. (discounting the learning curve of course

)

Roncallo · #14 10-24-2024, 08:40 PM

That is the real reason why I'm interested in this. Not only DAS components but I'm sure entire ECUs especially for the M120 V12 will not be available for long. So an aftermarket ECU and trans controller are now on my list.

I'm considering one of these online courses. Any recommendations.

https://www.hpacademy.com/courses/efi-tuning/

duxthe1 · #15 10-24-2024, 11:08 PM

All of those are probably good courses but my approach has always been feet first sink or swim. My suggestion is to actually try to tune a module. What trans module are you running in your project car?