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

97 SL320 · #16 10-05-2019, 06:38 AM

Quote:

Originally Posted by duxthe1

Lastly I did a bit of poking around on another "973" module and determined that the EHA's microcontroller pin uses a pulsewidth to control the circuitry. 1kHz on the pin equates to 20mA EHA current. I recall somewhere in WIS mentioning that the CIS "switches polarity" of the EHA current referencing decel fuel cut. I think it may have been literal and there is likely a microcontroller pin that actually signals a switch to negative current on the EHA.

Yes, I recall VW EHA info stating ( and providing an internal drawing ) that current is reversed to lean out fuel mixtures. The pic showed a metal diaphragm bending in both directions.

duxthe1 · #17 10-08-2019, 08:31 PM

Updating a bit early but its been a fruitful few days.

I've found a better 8051 simulator, that includes monitoring of the entire 256 bytes of internal memory and 64K of external memory. There are a few registers that aren't simulated but so far its the best I could find / afford. Its old software (2003) and the entity owning it only required a donation to a charitable organization to access the registered version. Commendable.

The real revelation came before the new simulator though. I found the section of code that deals with the variable stored from the analog read of the trim resistor input. Now having found the code, I've not disseminated it enough to understand how it ticks but I found something possibly more interesting. The relevant code is preceded by a spot of code that references a byte stored near the very end of the memory, well past the end of the program, near by where the bosch part number (found when converting the hex to ascii) is stored. This byte is used to decide whether or not to jump over the section of code that deals with the trim resistor value. The current value of this byte does in fact cause the code to jump past the relevant code.

Changing this byte to any other value will cause the code to execute. I also found another section of code referencing this very same byte and it will jump another section of code unless it is set to the value 0x04h. As of yet untested, but I'm expecting changing the byte will re-enable the trim resistor function in modules with it disabled.

Having made this revelation it is hard not to note that only a few lines above where this "trim resistor setting byte" is located, there is another 5 bytes in the middle of nothing. Searching for each of these individual addresses turns out that there is sections in the code that references each byte in a similar fashion of including the byte in conditional logic. I'd suppose these bytes perform the function of "variant coding" the module to the intended application. I can hypothesize that the 5 bytes may be cam adjuster, 2nd cam adjuster (v8), serial communication with ezl (104 and v8), v8 enrichment program (also different from 6 cyl) and lastly maybe ASR. Just hypothesis, for now though

duxthe1 · #18 10-18-2019, 07:45 PM

Another week passed and not too much progress to report. I received my 8051/8052 microcontroller book, though not in time to be out of town last weekend. Would have been great for several hours of sitting around an airport. Nonetheless I've read it in its entirety, at least everything pertinent. There weren't a lot of revelations, though one thing jumped out at me. CJNE. CJNE is an assembler programming instruction, and it stands for compare and jump if not equal. It compares two operands and if they are not equal it jumps to another address. On its face it doesn't appear to be an exceptionally useful instruction, but the book brought something to light that I hadn't before seen. If the first operand is less than the second operand then the carry bit will be set by the instruction. If the first operand is greater than the second, the carry bit will be cleared. This gives CJNE the ability to test if two operands are equal, greater than, or less than. That's a pretty powerful instruction, considering how simple and singularly focused most assembler instructions are. Once I really begin dissecting the CIS code, this tidbit will definitely help in understanding what is going on.

cth350 · #19 10-22-2019, 11:40 PM

I had a lot of fun doing what you're doing back in the 70s for TRS-80 programs in Z80 assembler. Learned a lot of things about shoehorning code into an eprom that way.

When you get to the point where you want to burn a new chip, google "eprom emulators" to get some more fungible hardware. What you really want for what you are doing is an in-circuit 8051 emulator, but they are not exactly cheap.

-CTH

duxthe1 · #20 10-24-2019, 06:20 PM

I've finally managed to score another CIS module compatible with my 300CE. Lowballing all of the vendors on ebay with the "make an offer" option payed off. These 55 pin modules never go bad and at least one vendor came to the conclusion that theirs wasn't a windfall waiting to happen and accepted my 30$ offer in mere minutes.

With a spare in hand I wasted no time swapping it for my current module noting the part number sticker on the eprom first. The new module is a "966" where my original is a "965". With the spare confirmed to be a good functional part I wasted no time pulling the original's 965 eprom. With the board out of the casing, I did a comparison against a 103 module. I noted that the 104 module has R37, R38, and D13 populated where the 103 module doesn't. This could help explain why I couldn't get any microcontroller pins to illicit a response for the cam control output on a 103 board.

The 965 eprom came off the board relatively easy, that or I'm starting to get really good at pulling them. Into the reader it went and I've got the code read out of it. Comparing the 104 code to the 103 code shows its damn near the same. Without doing any math I'd guess its over 95% identical. The small block at the end of memory has an ascii coded bosh part # just like the 973 code. The 5 bytes sitting alone a few lines above that block are all the same as the 973 code as well as the byte in the block that determines whether to skip over the trim resistor code.

Speaking of the trim resistor code, I went ahead and modified the 965 code to execute it. Additionally I changed the analog read of the trim resistor to the fixed value that would be read with a 953 ohm resistor. A chart in WIS lead me to believe that would be the value to use to get across the board enrichment at operating temp. To get that fixed value I set a potentiometer to ~950 ohms, connected it across the module pins, and measured the voltage present at the microcontroller pins. Plugging that voltage into an 8 bit ADC calculator yields the value and voila software coded trim resistor.

I burned my modified code into a 27C256 and installed it onto the original 965 board. Board back into the module box, module back into the car, and off to test drive. I can definitely see the effects of the modified code while monitoring the EHA current. The modified code resulted in significant enrichment during warmup, but not once warmed up. Given that all of the charts in WIS concerning resistor values have several trim options for warmup enrichment, I'm not too surprised this was the result. The chart I based my 953 ohm selection on, apparently isn't valid for this module. So at this point I'm going to have play with the trim resistor value.

Additionally there is a second section of code whose conditional execution is based on the same byte as the trim resistor code. I'm planning to re-enable that section, by itself, and with the trim resistor code to see if I can discern its function before trying other resistor values. I've only got a few 27C256 chips and currently don't have a UV eraser to blank them after written to.

This is finally starting to feel like progress

duxthe1 · #21 10-26-2019, 12:21 AM

Early update, but its worth it.

First off I enabled the secondary block of code that uses the same trim resistor enable byte. Test drive didn't reveal anything out of the ordinary, in terms of EHA current or overall driveability. That chip comes back out to be blanked and rewritten.

Next I decided try some other trim resistor values. Figured that even though I didn't start at the beginning I might as well go back to the beginning. The lowest value resistor in any of the charts is 487 ohm. Wrote its value into the appropriate register and took a test drive. I noted moderately more warmup enrichment than stock that tapered off by 60C. Pretty cool, but not what I'm after. The next value in line is the 953 ohm resistor, already tested and determined to give a lot of warmup enrichment tapering off at 80C.

The next value in line is 1270 ohms. The test drive with this value loaded gave a pretty good payoff.

This setting re-enabled WOT enrichment, which my CIS module previously did not have in any form. I have my EHA set where my closed loop current runs in a range of ~0 to -10mA with a mean average around -5mA.. Now when I hit the full throttle switch I get +2.5 to +3mA of current that ramps to over +6mA as RPM climbs. My EHA current monitor screen updates every 1/4 second and I noticed once when I punched it, that I momentarily caught a +60 mA reading. I only noticed it once in several WOT stabs, so it was either a fluke or there is also a very quick large shot of EHA current that only lasts a few milliseconds as the full load switch closes.

I also tried stabbing the throttle several times without closing the full load switch, aiming for 80-90% throttle. It was obvious that the enrichment doesn't kick in without the full load throttle switch closed. Now I'm not gonna say that 10-15mA worth of EHA current is life changing, but it is noticeable. If anyone is reading this that isn't familiar with the car, it has had a bit of work done in the head along with a longer duration intake cam. MY motivation for this endeavor was getting better fueling to complement the mods to the engine.

I could stop here and call it done, and be happy with my results.

Y'all should know that's not my style. I've still got 4 other resistor values to try. (after I finagle enough UV to blank my collection of chips) Barring any of the other resistor values having better results, I need to see if I can dissect the code that gave the enrichment and see if I can tweak it from there. Another consideration is that the 965 and 966 code is slightly different, 94 bytes different to be exact. After I get more blanked chips, (I'm out at the moment) I'm gonna mod the 966 code to see if it responds any differently. It didn't have WOT enrichment either and the major differences reside in data blocks and not code blocks.

Regardless, I now have a legitimately "chipped" 55pin CIS ECU!

duxthe1 · #22 11-01-2019, 10:52 PM

Not much to report. Snowed earlier in the week and the coupe hasn't been driven. In the meanwhile another ten 27C256 chips arrived as well as a UV eprom eraser. I've got all of my resistor values burned into different chips awaiting the opportunity to test them out. Testing will commence over the weekend.

97 SL320 · #23 11-02-2019, 08:26 AM

Rather than racking out the chips, you should be able to parallel everything together and use the " chip enable " / " output disable " to select the new chip. I'm not sure if you would need to restart the CPU or not but at least it will save physical changes of chips.

KarTek · #24 11-07-2019, 02:15 PM

I just wanted to say this is a very cool project! I have a fair understanding of what you're doing but not down to the bit/byte level.

Fascinating, at any rate even if I don't fully understand it.

RolandTiangco · #25 11-09-2019, 06:35 PM

What an excellent project. I’ll be following closely. If others were open, I would gladly...chip in...to help you get some dyno time once you’re ready for more serious testing before offering these up for sale to the community.

duxthe1 · #26 11-10-2019, 07:30 PM

I wouldn't ask anybody to chip in though at some point I'll want to enlist a few testers.

My goals here aren't so much a hp number but getting some amount of control over the EHA.

I was able to enable WOT throttle enrichment by selecting a trim resister value, but it wasn't permanent. Within a few test drives the function disappeared.

That was pretty disappointing but was at least proof of concept, it just needs work. I've tested all of the trim resistor functions and they are all pretty much various amounts of enrichment throughout warmup. None appear to influence mixture at full operating temp. I've added a few subroutines to modify some of the variables with varying amounts of success. I've also written a subroutine to clear the external eeprom at the startup of the module. I postulated that whatever disabled the new found WOT enrichment was being written to the eeprom. Clearing the eeprom didn't re-enable the WOT function like I had hoped but it is still a nifty trick to have. My new working theory is that there was a value previously written into the eeprom that when combined with the newly activated trim resistor function resulted in the WOT enrichment being enabled, but as old values were overwitten with new, the function became disabled.

In the continuing endeavor of mapping the module inputs to the microcontroller I've identified another analog input. AN6 is the current monitor of the EHA. I can only assume this is for fault monitoring since there is an "EHA current" fault code possible with these modules. I'm still yet to identify AN7, AN1 and AN0. One of them has to be O2 sensor signal and presumably another is idle valve current monitor and the third I don't have a guess for yet. O2 signal isn't directly fed to the microcontroller but preconditioned in the module and without simulating (or testing on) a running engine with the module I'm not going to be able to divine where O2 is read.

Another input I've been keen to locate is the full load throttle switch. I've traced it through the module but I've yet to make sense of it. The signal is preconditioned through one of the ceramic mini circuit boards soldered perpendicular to the main module board. It enters that mini board already a 5V signal (at the module input its a 12V signal) and is inverted at the output of the ceramic mini-board. The confusing part is that when it switches the value only drops about .5V and more confusing is that the complementary idle switch also outputs the mini board at the same location but drops the signal about .8V This signal isn't going to an analog input so as of yet it doesn't make a lot of sense. Another situation of needing to test on a running engine. Maybe this week I can get around to it....

duxthe1 · #27 11-15-2019, 08:00 PM

I got around to doing a little testing on a running engine. I have a 103 module with the 973 eprom that's my test mule so I plugged it in and warmed up the engine. The full load switch and idle switch still didn't seem to make any sense. I'd really like to get that figured out but that's for another day. I was able to locate where RPM is read, and its not the pin I thought. I haven't really looked though the code yet to see how its being used.

The big revelation was figuring out the oxygen sensor signal. I was pretty certain it would be read on one of the remaining undefined analog input pins. I was wrong. The circuitry on the module board pre-conditions the oxygen sensor signal into a binary rich / lean input for one of the digital pins. All things considered that's probably a lot easier for the software to deal with than an analog read of the O2 sensor. I've looked though the code and found a few sections that deal with the O2 input. I haven't studied them in detail but I noticed that the state of the pin gets read into the carry bit for manipulation and stored in another address presumably for use by other sections of code. There's still a lot of the code that I don't have any idea what its doing but the bigger picture is starting to come into focus.

At this point I've still got 3 analog inputs that I haven't defined. I'm pretty certain one of the three is idle valve monitoring, but the other 2 have me stumped at the moment. I need to look at the full list of fault codes for this module to see if any would require an analog read to determine the fault condition. Not a high priority but being able to see sections of code dealing exclusively with fault monitoring would allow me to better focus on other more relevant code.

duxthe1 · #28 11-22-2019, 11:38 PM

Literally nothing for this week's update. I had some other projects that needed my attention and after spending a lot of free time over the last couple months focusing on this project I wanted to take a break so that once I'm ready I can come back to it with a fresh perspective. In the meantime I've just been driving around, weather permitting, on one of my modified versions of code just to get a good feel of what its doing under lots of different driving conditions.

duxthe1 · #29 12-13-2019, 08:57 PM

I've gotten back into this project and today was going to be a big day for me. I managed to buy a 500 SL module and it was delivered today. After comparing wiring diagrams and confirming all of the major functions are present on the same pins, I've been real keen to get my hands on one. It didn't take long after getting in for the evening to open the box and unscrew the cover from the module. This is where my hopes were dashed. Despite a very similar pinout (the connector even plugs in without issue) the circuit board is wholesale different, and there is no 27c256 eprom to remove and read. There are two SMT chips at either corner of the board with shriveled part# stickers, likely where the program resides for this module.

This is a huge disappointment for me because there are a few subtle differences in the function of the 119 module v/s the 104 module and being able to find them in the code would have given me a big leg up on changing the idle speed as well as EHA control. Given that there is an additional tach pulse per revolution, the idle control code would have to account for that and that would have pointed exactly to where in the code the idle timer target resides. The 119 has about 75mA of key on engine off EHA current v/s the 104's (and 103's) 20mA. Finding that difference in the code would have been big too.

Another disappointing consideration is that this 119 module has WOT enrichment. I wasn't sure it would but I confirmed that it does by installing it and going for a spin. A few things I noticed running the 119 module on my 104. First off, check engine light. I didn't read codes but there are a few superficial differences and they immediately set a C/E light. Idle speed is high because time between tach pulses is long from the 119 module's perspective. Cam timing switchover is late for the same reason but gives a noticeable surge of power when it does finally come on. WOT enrichement is also noticeable and only makes me more determined to get it working in the 6 cyl code. The 75 mA KOEO EHA current is too rich and floods the engine when you crank it. You have to give it a bit of throttle to clear it enough to start.

At this point its back to the drawing board. This 500 SL module is 011 545 23 32. There are a few other numbers that could be valid, likely the difference between years and federal or California version. I'd love to get a look inside of a 008 545 77 32 and just to make sure there wasn't an early version based on the familiar 6 cyl board..

97 SL320 · #30 12-18-2019, 07:47 PM

Carefully note the numbers on the stickers and remove them, the chips will still be marked. Older stuff is paint but later is laser etched so don't use any solvents just yet.

Also, check the e mail account attached to this forum, you've got mail.