A quick update this evening, After a few hours of staring at assembly, I now "understand" around 200 lines of code the ECU runs when it Resets. To give you some idea, the key hasn't even been on for 500 ms and the fuel pump is still priming. Only got around 3000 lines left Interesting points: I found several points of code that cannot be accessed during normal running. One odd example is the processing checking for 5 volts to itself, which obviously it would't be able to check if it had 5 volts. So this is either an error on my part or possible a piece of code left over from development/another ECU model I've found a fail-safe for a shorted IAT sensor. I can't immediately see one for a "open-circuit" sensor, which makes sense if you think about it because if the sensor wasn't there it would just make the ECU think its very cold and run the engine rich. However, a shorted sensor would represent intake temperatures of over 100 degrees C. Adding to this point, I've not looked into what the ECU does, but it does make a distinction between normal and shorted I found a map which adjusts something based on battery voltage. Could be idle speed or possibly crank time before injecting fuel. Any ideas? I have found a ECT map. I need to a lot do a lot of work on understanding how this ECU works because I'm not sure if there is only one ECT map or if there are multiple that are selected by IAT's. That's a few hours work on its own because the code jumps around a lot in that area. Again any ideas?? EDIT: The ECT map I've found is something to do with cold start I would guess, it tops out at 65C but goes way below 0. I've got a temp sender in my freezer to take some values off tomorrow
Thanks Jon! Does anyone have any other ideas what maps there might be outside the "normal" Fuel, ECT, IAT and battery? Just trying to think of some so I know what I'm looking for. Unlike a modern software on a modern computer where, if you know the language, you can also immediately see and understand what the code is doing. However, with assembly, you end up having to think like the person that wrote the code initially in order to understand what they were doing at each stage. The only saving grace is that as the CPU is nearly 45 years old there isn't that much memory or registers so you can almost keep track of everything in your head. However, on the flip slide, the lack of features means that there is some code that is really "awkward" because that was the only way they could get the processor to do what they wanted. And if anyone is wondering, I am using the NSA (yes that one) tool Ghidra with custom disassembler for the old CPU.
Rather look for opinions, look at the electrical hardware on the engine so you, the developer, can determine want might be electronically coded in the ECU. A knowledge of engine combustion, fuel economy and legislative trends is helpful but not always necessary for some of the developers I work with. Digifant 2 engines run on typical Bosch AFM hardware. So inputs and outputs will be pretty common for that era.
Thank you Toyotec! Another small update with some good/bad information, mainly relating to the possibility of diagnostics. As mentioned previously, their are two "types" of ECU, single letter and double letter, with the double letter design having the connector integrated inside the heatsink. From the research I've done, the single letter ECU's (the 3 I bought) were made exclusively by Bosch, and almost no of the aftermarket chips available are compatible with this ECU. The double letter design however was made by Bosch, Siemens, TAN/TA? and KEN (Kraftfahrzeug-Elektronik Nürnberg) and is the one that is the most "tunable". From the small amount of testing I've done it seems that the mapping of external pins to processor inputs is effectively the same (although I've not tested everything), which would in theory mean the chips from both ECU types could be interchanged. When my programmer arrives I am going to compare the dump from one of my EEPROMs to that of a double letter ECU to see if there are any differences (if anyone has a ECU or EEPROM dump that would be amazing). As for the "Blink Code" Diagnostics ability, this is not possible by default on 037 906 022 N as a internal transistor is missing a shorting link has been installed. I will try retro-fitting the transistor and removing the link to see if I can get it to work.
Not managed to have much time on this project recently, but I had a look today and thought I'd post another small update. If anyone is unfamiliar with assembly I've attached a screenshot below of a section of code that runs during the startup of the ECU. The left columns are address and raw data, the centre two are disassembled instructions and the right is my comments. As you can the comments are far from complete but they're enough for me to understand roughly what is going on, which is my aim. For example, in the screenshot above the processor is doing the first configuration of its output pins which includes switching the fuel pump on to prime. Here is also one of the fuel maps, the duration is 0-255 and it takes load values on one axis and RPM on the other. The load bank will be selected using a combination of various ECU inputs which I've yet to detail. The RPM should be fairly easy to check but is handled in a Interrupt routine which, again, I'm yet to look at: Aside from the mapping I'm also looking at writing some code to add an internal immobiliser to the ECU. This is totally for my own entertainment but will work by replacing the ECU startup routine with my own that will check the certain parameters are met before allowing the processor to return to normal operating conditions.
great stuff, interesting to see the assembler code though its been over 20 years since I last had to deal with it so can't really follow it so well
I'm glad people are finding some interest in it! I might set up a GitHub to show my work in progress files if that's something people would like? Spent some more time on this today and I've come to a bit of sticking point, well two actually. The first is illustrated below: Effectively, when the ECU receives a pulse from the hall sensor it jumps to "HallPulse" The program them carries on down towards address 40 where it then jumps again and executes the RETR function to exit the interrupt routine and return to the location that was in the program. So it appears that the processor can never get any further into the routine. I think I need to do more reading on the CPU as this obviously isn't right The second issue is somewhat related. The reason I'm looking at the Interrupt routines is to decern how the ECU calculates RPM. I've yet to decern that but I have found something else interesting. There is a value in RAM that is used to select a small region within one of the fuel maps. It ranges from approx 2500 rpm to redline at low load between 6 and 3. Its used in lots of places but the screenshot first fuel map which I believe is the map selected when Lambda is in use but the part throttle high RPM range doesn't seem to make sense for a lambda range? Or does it? Again a bit stumped here.
Some EU models with PF code engines or in the Passat, run closed loop lambda. PB engines are open loop. Based on what I have seen from mapping VW/Audi Bosch engine control over the years, before planer sensors, at from mid to high loads and from a threshold engine speed, you are in open loop.
Long overdue update! Due to life getting in the way and having to actually get my MK2 back on the road this project has taken a back seat. I've spent some time trying to track down the Australian "setgti" or "set" or Vortex as he fully dissembled the code in the past. I've also been speaking to a couple of Russians that have been helpful to cross-reference our understanding of the code. I have an EPROM programmer now which means I can compare my ECU's to online files. So far they are identical except my ECU's have an extra NOP at the start of execution so everything is offset my one instruction for some reason. I've yet to open my "two letter" ECU, but expect this to have significantly different code. I've also started collecting parts to build a reader for the Motorola timing controller. This will be the most interesting part by far as its not been done before. I'm going to write a universal-ish emulator that can be used with both chips. It will also be able to emulate the engine. This will save me having to keep erasing and flashing the EPROM and will make disassembly far easier as I can actually test ideas. Its going to be written in Python and will be fairly tedious as it's going to involve writing functions for every instruction of both instruction sets. I'll post all of the work on GitHub as I go along. So in-summary this project is not dead its just I have no time at the moment!
Deleted the last post because I was being defeatist I have found most of the maps now I am just looking into how the they are used by the ECU. 3x Load vs RPM maps These are what the ECU used to take the raw value from the VAM and the RPM to calculate the base injector value. Two are selected between in hardware at the factory (country dependant) the third one as I understand is used in setup mode. ECT Maps The base injector value is modified by various ECT maps. I have found 6 so far. I am not quite sure how these work yet, @Toyotec can you shed any light from when you used to tune them? IAT So far I have 2 maps for this. One that appears to be used during start-up and one that is used during normal running to modify the injector duration, similar to ECT. Misc There are maps that relate to battery voltage, again not sure what this does, and a map that sets the Max Airflow per RPM which I found quite interesting. If the engine flows above it this, the ECU caps it down to this map. Could be interesting how this works with 2 litre engines. Other notes RPM limiter: There isn't a hard limit as such, I believe the limit is caused by leaning off the fuel maps, and is possibly implemented by ignition cut on the other processor too Map Scales: This is a tough one. Unlike a " modern" ECU, the scales are not stored with the maps and have to be calculated. I have done this for the ECT and IAT maps but not for RPM. (VAM is sort of calculated live rather than using a Map, although it should be possible to extract voltage ranges that relate to each block in the fuel map) RPM has been calculated before by a couple of Vortexers by running through the 16-bit math functions. This is hard and I have not done this yet to confirm. Other other: The ECU performs linear interpolation and 16-bit comparisons using only a 8-bit CPU that lacks subtract, divide and multiply instructions. Its very impressive but makes reverse engineering very tedious. I am still working on the design to read the Motorola timing processor because I will be very interested to look at the maps, and see how the "style" of the code differs being from different era. Find the code so far on: GitHub
I admire you. Are you enjoying it? There HAS to be a market for this, with all the 8v GTI and G60 cars out there.
Yeah its something to do when the weather is bad of course, and its interesting seeing how they made a complex controller like an ECU using really basic hardware. Really impressive considering how easy it would be replicate that functionality with a modern procesor. Yeah I imagine there is! I am very, very curious what happened to "set" and "xr4tic" along with their work. I know "set" owned a pro-audio business in Australia and have fully disassembled the code and located all the maps. He made it public too! I've tried to get in contact with him through several forums and e-mail but he really seems totally opposed to discussing. Not sure if he has some bad memories attached to it/his business or he sold it someone and got told not to discuss it. Its very odd anyway. The end goal as mentioned earlier is to make several chips for different cams and other tweaks like 2.0 conversion and importantly, getting rid of the VAM
Digifant 1 for G60 and G40 has been done and is already known. Digifant 2 on the other hand, we tuners are limited, due to little information for ignition timing and rev cut. Fuel control, we know what to do.
Interesting stuff, keep it up! I've messed with a bit of assembly code in the past, so would be interested to have a look via Github.
Yeah G40/G60 is fairly well documented and use a much more "modern" approach, even though the "I" would imply its older. Digi 2 has never really been touched I guess because its a lot of effort for little reward compared to a boosted car. It is quite basic but with the ability to change timing it should be fairly capable! An American company called AMS did actually offer a "chip" for around $300 back in 2000 that altered timing. You had to send the ECU to them and then it came back with various tweaks including more power, higher rev limit and ignoring the blue temp sender when up to temperature. From the very limited information I've seen that some people say that AMS "piggybacked" onto the microcontroller with their own device and some people say they "made their own chip". Without having one to look at I think all they did was write their own code from scratch and flashed it to the processor. Speculating but I would guess the code the wrote was quite simple and didn't have cold start logic and proper temperature compensation like the factory code as many people reported cold start issues. @Mk2daz I'll get it update and put a link of here. I'll put the Ghidra project file up too along with my fixed disassembler . It has pseudo code generation which is very useful and surprising good. Does anyone have any info on DigiFast Chips?
I actually one of the few who bothered investigate and burnt a fuel flash eprom, after multiple dyno pulls, which addressed the fuel control table. I did not do any "fuel mods" and was way more advanced than that. This was for a PGTI 8v car and "ECU corrections" were allowed. What I found was, while you can clean up the nasty dip to 11.8 AFR at the midrange of a WOT pull with tuning, you found yourself opening out the injection duration to stop the lambda from heading lean to 14 AFR or leaner to the 6200 rpm cut out. At the top end, you just about got to LBT or 13.4 AFR. Without the ability to alter the ignition though, where most of the engine's torque will come from, you found yourself pissing in the wind. Run a 2E on the bottom of a PB/PF cylinder head and more compromise. In the end on my own car with a 2.0 3A motor, I just binned the digifant 2 and fitted Megasquirt. What I found with that was, the bhp at 5000 was marginally improved @ 5500, but nothing to shout about. However torque spread from 2100 rpm to 3800 rpm was flat and driveablity everywhere increased, to make a true 0- 60 in 7.8 secs 2.0 8v engine. I can see full access to digifant 2, helping engines, such as say a 2.0 8v, running a 272 cam, providing the airflow is not too disruptive to low speed on the AFM. However those ECUs also lack logging data which the most basic SEM has these days. So you need someone determined to map them, just like you have to be with KJet. It is a good project, that I would argue might have some limited scope.