Going to post a little bit more on topic.
Something that is very helpful in finding things is having many different ECU files.
If you take the 27C512 files from the 551C ECU from an S6 and a 551C ECU from an RS2 they are almost identical, the only difference is in the maps and some constants. This eases the task a lot.
To look deeper into this, one must understand how the EPROM is generally laid out.
From what I understand this applies to any ECU used in cars with the AAN, ABY and ADU engines. When you have many files, you can find some similar ones. For example by comparing the software of the late RS2 with the S6 from the ECU with the same number, you can figure out a lot of things.
This seems to be the EPROM layout of the 27C512 chip:
From 0x0000 to 0x1FFFF you have from what I understand the main Bosch software provided with any ECU. From what I have read, it used to be in the internal ROM of the CPU in earlier motronics. Luckily it does not seem to be the case here.
From 0x2000 to 0x7FFF (in the later "C" ecu-s to 0x9FFF) should be the manufacturer specific code.
Actually it is not that important to know which code belongs to whom, just that 0x0000 to 0x7FFF (or 0x9FFF) is mostly code that can be disassembled and looked at.
After this, at 0x8000 (A, AA, B) or 0xA000 (C) comes some more data that is static between different car types. I haven't tried to figure out what it is yet.
Things get interesting after another 300h (0xA300 or 0x8300), where there is a small block of data, some padding and after 20h more (0xA320 or 0x8320) there is a data area, which varies between different cars. The rev limiter is located in this area, and at my guess perhaps the "injector constants" (krkte) are somewhere around here as well.
Now comes one of the most important parts. At 0x8800 or 0xA800 in the later ECU-s is the master table. It simply contains all 16 bit addresses of the tables found in the ECU. At my guess (again... I hate guessing), almost every table that is referenced by the ECU is here. The only things that are exempt are the constants, such as the rev limiter, about the location of which I wrote above.
Finally we get to the map data. From 0x8A00 (0xAA00) until 0xFEFF we have all the maps one after another, as referenced by the map table above. The maps are dynamic. It is possible to resize and rescale them, and the ECU will cope. This is evidenced by the fact, that software for the ADU engine is exactly the same as for AAN (bar one byte) and the maps have different dimensions.
There is enough information online on how to read the maps, no point for me to repeat it here.
And now we are done. At 0xFF00 we have the checksum, after which we have the ECU version, then for lack of a better name "the string that gets displayed in VAG-COM" and finally the exact version of the software.
So, this is the structure of the fuel chip. We also of course have the turbo chip, but that is for another time.
The difficulty comes from understanding what each of these maps and constants do, and how they are read. This is where the real work begins.
One can get some hints from the assembly:
The 8051 CPU always uses it's 16 bit register (DPTR) to load data from external memory (EPROM). One of the instructions to load a static location, is MOV DPTR, #data. In hex it is 90 followed by the address. Interaction with the register is little-endian, so if you want to check whether the CPU directly loads a value from somewhere, you can just try to search for 90 XX XX in the hex code. Of course there are other ways to modify the data pointer, but just searching for all memory accesses in the code and mapping them out (while weeding out false positives) will give you a rough idea of what code touches what.
However, from what I gather (and from what I have been told), it is almost impossible to figure this thing out by assembly alone. A trace and some data logging is required, so that you can get rough ideas on how the multitude of analogue signals coming in and going out of the ECU are scaled and represented in digital form within the ECU software itself.
I hope this is of some help to someone. Some mistakes might have slipped in, so feel free to correct me, if I got something wrong.
Oh and, if anyone wants to help me along with figuring a few things out, It'd be pretty cool. Whether it is done in public or privately. Though from what I have seen, if you start digging in this thing, you need to have a head of your own.
Something that is very helpful in finding things is having many different ECU files.
If you take the 27C512 files from the 551C ECU from an S6 and a 551C ECU from an RS2 they are almost identical, the only difference is in the maps and some constants. This eases the task a lot.
To look deeper into this, one must understand how the EPROM is generally laid out.
From what I understand this applies to any ECU used in cars with the AAN, ABY and ADU engines. When you have many files, you can find some similar ones. For example by comparing the software of the late RS2 with the S6 from the ECU with the same number, you can figure out a lot of things.
This seems to be the EPROM layout of the 27C512 chip:
From 0x0000 to 0x1FFFF you have from what I understand the main Bosch software provided with any ECU. From what I have read, it used to be in the internal ROM of the CPU in earlier motronics. Luckily it does not seem to be the case here.
From 0x2000 to 0x7FFF (in the later "C" ecu-s to 0x9FFF) should be the manufacturer specific code.
Actually it is not that important to know which code belongs to whom, just that 0x0000 to 0x7FFF (or 0x9FFF) is mostly code that can be disassembled and looked at.
After this, at 0x8000 (A, AA, B) or 0xA000 (C) comes some more data that is static between different car types. I haven't tried to figure out what it is yet.
Things get interesting after another 300h (0xA300 or 0x8300), where there is a small block of data, some padding and after 20h more (0xA320 or 0x8320) there is a data area, which varies between different cars. The rev limiter is located in this area, and at my guess perhaps the "injector constants" (krkte) are somewhere around here as well.
Now comes one of the most important parts. At 0x8800 or 0xA800 in the later ECU-s is the master table. It simply contains all 16 bit addresses of the tables found in the ECU. At my guess (again... I hate guessing), almost every table that is referenced by the ECU is here. The only things that are exempt are the constants, such as the rev limiter, about the location of which I wrote above.
Finally we get to the map data. From 0x8A00 (0xAA00) until 0xFEFF we have all the maps one after another, as referenced by the map table above. The maps are dynamic. It is possible to resize and rescale them, and the ECU will cope. This is evidenced by the fact, that software for the ADU engine is exactly the same as for AAN (bar one byte) and the maps have different dimensions.
There is enough information online on how to read the maps, no point for me to repeat it here.
And now we are done. At 0xFF00 we have the checksum, after which we have the ECU version, then for lack of a better name "the string that gets displayed in VAG-COM" and finally the exact version of the software.
So, this is the structure of the fuel chip. We also of course have the turbo chip, but that is for another time.
The difficulty comes from understanding what each of these maps and constants do, and how they are read. This is where the real work begins.
One can get some hints from the assembly:
The 8051 CPU always uses it's 16 bit register (DPTR) to load data from external memory (EPROM). One of the instructions to load a static location, is MOV DPTR, #data. In hex it is 90 followed by the address. Interaction with the register is little-endian, so if you want to check whether the CPU directly loads a value from somewhere, you can just try to search for 90 XX XX in the hex code. Of course there are other ways to modify the data pointer, but just searching for all memory accesses in the code and mapping them out (while weeding out false positives) will give you a rough idea of what code touches what.
However, from what I gather (and from what I have been told), it is almost impossible to figure this thing out by assembly alone. A trace and some data logging is required, so that you can get rough ideas on how the multitude of analogue signals coming in and going out of the ECU are scaled and represented in digital form within the ECU software itself.
I hope this is of some help to someone. Some mistakes might have slipped in, so feel free to correct me, if I got something wrong.
Oh and, if anyone wants to help me along with figuring a few things out, It'd be pretty cool. Whether it is done in public or privately. Though from what I have seen, if you start digging in this thing, you need to have a head of your own.
.
Comment