"Chipping" a CIS ECU - Page 3 - PeachParts Mercedes-Benz Forum

duxthe1 · #31 12-18-2019, 08:42 PM

Heck of a good cross reference, thanks. While I am curious about the inner workings of this 500 SL module, it would be a whole other endeavor to try to get its programming pulled out and understood. With it targeted to a different board, I'm not terribly optimistic it would be very enlightening. The current project is overwhelming enough that I'm just going to offer the module for sale unmolested to recoup the few dollars invested.

One last opportunity to examine another variant is to get my hands on a 190E 2.3 module from a 91-93 car. WIS states specifically that those do not have a NON-KAT option in the programming. Its idle code should be slightly different too, given the 2 vs 3 tach pulses per rev. I'm on the lookout but ebay shows a lack of credible offerings. Nonetheless I do have a few "make an offer" lowball bids in.

I spent a little time last night working though a few subroutines and I think I found what the trim resistor values (as read by the module, not actual ohms) should be. My previous attempts were using values based on published values from other modules. I'm going to retest over the next few days using each of these new found values and see if any new results emerge. Will update as results come in.

duxthe1 · #32 12-22-2019, 08:19 PM

Had an opportunity to test the newly found trim values. What I found was that a few of them appeared to set the module into Non-Kat(alyst) mode. What stands out is that the closed loop oscillation is missing. The first time I noticed it was after winding it out on a merge onto 3 lanes and not knowing (at the time) what was going on I had thought maybe the O2 sensor had given up. I loaded stock code on an eprom to double check and sure enough the O2 is ok. Subsequent testing shows a few of the trim values just don't go into closed loop. Other EHA control functions are ok. Decel fuel cut works the same and accel enrichment is also fine, with varying amounts depending on trim value and temperature. Instead of closed loop operation there is a relatively fixed EHA current during steady state operation that appears to be based on an average O2 reading. At operating temp that average current seems to be a bit leaner than closed loop operation at the same relative conditions. Depending on the selected trim value, enrichment during warmup could be significant , or sparse. One setting in particular was generous with warmup enrichment as well as accel enrichment and had WOT enrichment to about 70 deg C.

Being that my coupe is US spec and catalyst equipped, I'm not planning to do any long term testing of the Non-Kat modes. I cant say that this got me any further towards my goal, but every bit of understanding I can glean is working in the right direction.

duxthe1 · #33 12-27-2019, 08:38 PM

I've spent the week working on the additional subroutines I've added to the code. I've managed to get WOT enrichment enabled, while keeping closed loop operation functional when not WOT, and also keeping the module from being able to adapt it back out. Its pretty close to what I wanted to accomplish in terms of enrichment, and it is complementing my engine mods nicely. I'd still like to get the idle code figured out, since I want to raise the idle target in hot weather to help prevent overheating at stoplights. Obviously not an immediate issue, but I'll keep plugging along until I get it figured out.

This is the point that I'd like to enlist a couple of testers to try out the modification to the code in vehicles other than my own. I'm going to offer to mod one module for a 103, and one for a 104.980, keeping in mind that these are the metal box, 55pin modules. You ship me a module and 20$ to cover supplies and I'll remove the eprom, install a socket and load my code on an eprom and install it. PM me to set it up, first reply for either engine gets this opportunity.

duxthe1 · #34 01-16-2020, 08:56 PM

Despite having a pretty good performing code I've still been at it. I've begun using a brute force technique on the constants and data tables. From about 0300h to about 0900h the program is filled in with values that when transcribed into assembler form no coherent programing. Thus presumably it is mostly constants and data tables. Staring at the raw values it is even possible to pick out what appears to be a few tables in the mix of otherwise random values.

The brute force technique I'm employing is to take one line (16 bytes) of this data field at a time and increase each byte by 20h. Then I load the code and drive the car. If I notice something happening different (and of interest) I proceed to figure out what byte change caused it. I split the line of 16 bytes into two sections of 8 bytes and only add the 20h to half and retest the code. I repeat this halving process until I can pinpoint the exact byte causing the change. I've only run through a few lines so far but I have identified the exact byte that that sets the key on engine off EHA current to 20 mA. I can change the byte and alter this parameter in 20ma increments. Not super useful in itself but since it deals with EHA current directly it can help identify more useful program code further down the line.

I've noted a few other oddball changes but they weren't significant or useful enough to pinpoint, so I just make notes indicating the change happened in a certain line of code. A relatively large quick shot of enrichment on sudden throttle lifts was one, and the loss of decel fuel cut under most circumstances another. Neither seem to helpful right now but I can revisit the line of code later if the need arises.

I also want to give a big thanks to member CTH350 for taking his time and spending a few bucks to ship me his spare eproms and an eprom eraser.

Given that I'm constantly pulling and reseating chips on these boards, bent pins turn into broken pins and chips that hit the floor don't always end up whole. The spares were greatly appreciated. The spares sent were 27C512. These are twice the capacity of the specified 27C256 and while a direct write doesn't work, offsetting the write to 8000h lets them function as a drop in replacement.

97 SL320 · #35 01-18-2020, 07:09 PM

Quote:

Originally Posted by duxthe1

Given that I'm constantly pulling and reseating chips on these boards, bent pins turn into broken pins and chips that hit the floor don't always end up whole.

Why not use a ZIF ( Zero Insertion Force ) socket like the programmer uses? If this won't fit, use a ribbon cable with a DIP on one end and the ZIF on the other to bring the chip outside the ECU box.

duxthe1 · #36 01-19-2020, 12:13 AM

My testing is pretty much all done in real world driving and the module sits in the cowling just aft of the battery. It is shielded but its not a true weatherproof location. Most of the structure around the module is aluminum, though I no longer bother to bolt the module to it. With the possibility of weather and electrical shorts causing damage, external exposure is precluded. The zif socket isn't a bad idea, but they tend to be bulky, I'd have to see if I could fit one onto the board and still get its cover on. I'm gonna look into it on the next module I convert for testing.

97 SL320 · #37 01-19-2020, 09:10 AM

I've seen thin outline ZIF sockets that use a screwdriver to lock, the are about 3/8" longer than a standard socket. I can't find an example, but here are a few low profile latching units.

https://www.arieselec.com/products/data/10017-dip-zif-test-socket.htm

https://www.arieselec.com/products/data/10018-low-profile-zif-test-socket.htm

In order to gain weather resistance, I'd make a " mail flap " hole in the ECU case for the ribbon cable to exit then use thin foam to seal the opening. The stack up would be case / foam / ribbon cable / foam / mail flap. The flap does not need to be on a hinge, 2 screws on either end should be enough.

For the other end, use a small plastic project box with the same type of ribbon cable entry. This way you can use a full sized ZIF.

And,. . .if you really want to get tricky, bus the chips all together then use the read inhibit line to select between chips. This way you can try make changes in two different areas and gather both sets of data in the same trip ( RE: one chip has spark changed and the other fuel or change one area to two differing degrees.

sm. pelle · #38 01-21-2020, 04:11 AM

Are u using winols to read file?

duxthe1 · #39 01-21-2020, 01:29 PM

No, I'm using a GQ 4x4 programmer and doing read / writes through its native software. I use Spicelogic 8051 disassembler, FlexHex, Simulator 2003, and ICY Hexplorer as the main programs to manipulate and simulate the files.

duxthe1 · #40 01-24-2020, 08:43 PM

It's been a week of plugging through line after line of the constants and data tables. I found a byte that appeared to give a rev limit and at my test value kicked in at 5500 RPM. It gave a pretty cool sounding stutter when it kicked in, like being on a two step but at 5500

Comparing it to the 103's code which should have a lower rev limit than the 104.980, I couldn't reconcile the byte as being the actual rev limiter. A fluke at best.

Eventually, I got through the random data and hit a section that obviously appeared to be data tables. Specifically 3 data tables between 40 and 50 bytes each. Instead of altering these line by line, I altered each table as a whole by doubling their values or setting a very high value if doubling exceeded 255 (FFh). The first table didn't appear to do anything extraordinary as driving from a very cold start through warmup. (The drive to work this morning). I subjectively thought that maybe the cold transient enrichments may have been more than usual with this otherwise stock code, but it certainly wasn't an in your face change.

I tested the second table being mostly doubled at lunch. HOLY COW! The thing ran gobsmackingly rich. +50mA rich

Overnight cold start at 20F this morning only hit +35mA for comparison. As it warmed up the EHA current only dropped by a small amount, though once fully warmed up it did start going into decel fuel cut. Thankfully the lunch destination was pretty close because at this rate of fueling it was bogging pretty bad and would likely melt down a catalyst if ran very far.

I've yet to test the third table but its a high priority for tomorrow. Meanwhile this 2nd table is a pretty big find. Now that I know it has a huge impact on fueling, I'm going to have to work on modifying it in such a manner as to begin correlating its values to actual EHA currents as well as the conditions under which they apply. This could be my holy grail. I don't want to call it too soon, but the potential is there.

duxthe1 · #41 01-26-2020, 06:45 PM

After a day's worth of additional testing, its worth an early update.

Modified the third table and test drove, no noticeable differences noted. This table is the only one of the 3 tables that is different between the 103 and 104.980. I haven't yet proved it and likely wont spend the effort but I highly suspect that these tables are being selected based on the trim resistor.

The real story is that table 2 holds a lot of significance to the enrichments. I plotted out the data in table 2 and attached a pic. Just slightly modifying the first curve had big results. Warmup enrichment was quite generous. Idle approach was also a fair bit rich. What I call idle approach is a shot of enrichment as coasting down and preparing to enter closed loop idle. Once warm, closed loop mixture control was normal, oscillating in the normal ranges. Decel fuel cut was also still working normally. Now, for the coup de gras… the slight mod to the table was providing 20mA plus of positive WOT enrichment!

I was careful to test near WOT and full WOT and closed loop mixture was maintained until closing the WOT switch.

There is a lot of data in this table and there's still a lot of testing I want to do with it. The one drawback with the last mod to the table is that is slow to come out of the enrichment modes, taking a few seconds to taper down into closed loop. Typically this happens almost instantly.

Despite the slow release of enrichment, this code was driving pretty awesome. SWMBO commented that it sounded like the "black wagon", a gone but not forgotten TE that had a muffler delete. This despite the coupe having a full exhaust, though not a stock muffler. It's exhaust note was definitely crisp, but I feel like 20 mA may have been a bit overly rich. After I get good control of this table I may end up installing a wideband O2 for better tuning ability.

SpartanV · #42 02-05-2020, 05:13 AM

Still following your thread.

Seems you're on to something!

How are you monitoring EHA current when driving, long ass leads to the cabin? lol

duxthe1 · #43 02-05-2020, 07:46 PM

Quote:

Originally Posted by SpartanV

Still following your thread.

Seems you're on to something!

How are you monitoring EHA current when driving, long ass leads to the cabin? lol

I built a current monitor using an Arduino Pro-Mini and display the EHA current and air flow potentiometer voltage as well as MAFdot and RPMdot on a small LCD screen that I've 3d printed a housing for that sits well in the instrument cluster. I took a couple pics, attached.

I'm still working on making sense of the data table. It doesn't appear that its a direct mapping of enrichment. There is 1 byte that if changed from a 0 to a 1 it triggers ~20mA of enrichment when the WOT switch is released. Other bytes trigger enrichment only through certain RPM ranges or defeat afterstart or warmup enrichment. Currently the weather has the car blanketed in snow with more in the forecast so testing is on hold.