ecuedit wrote:Hi,
for all information you would have to get source code for compiling sw to bin ;)
Thats's quite a top secret...
There is no easy way for sure.
Its bad that every sw no. has maps and data on different addresses.
But everything can be done.
It would be interesting to know if they intentionally make signature bytes different in different versions of SW, or is it just a consequence of evolving software?
Going out on a limb here, so bear with me ;)
At some point in time factory makes version 1 of software, compiles it, burns it to ECU, configures the parameters, tunes it and uses it in cars that come off the production line from day 0.
After some time passes, bugs are found either in software or hardware, maybe some hardware components need changing, or changes to car was made (face lift, whatever).
Now they are forced to make fixes to the software source code 1 and release it as 2. They want to do fixes at minimum as much as possible - solve the problem but do not introduce changes and new bugs to other functioning parts - don't fix it if it ain't broken. Maybe a function needed fixing, new constant added or removed, improve some algorithm, whatever. All these software changes in source code 2 result in the bin file changes. Offsets move, values are a bit different, etc. Usually executable and data parts of the binary are separated (this has to do with CPU - memory wiring and the way CPU works). Executable bits is what a CPU takes as commands to execute (load value, store value, add, subtract,..) and data bits are what gets loaded, stored, added, subtracted by those commands. Calculation results are temporary saved in the RAM memory not in EEPROM, which is not so important right now. If I wanted to know more, I would need CPU datasheet and wiring schematic to the ECU.
In my study I compared three bins from the same make, model, year, ecu BUT different software versions (I used 406 2.2 HDI EDC15C2 bins found on this forum)., SW versions 1037353776 vs. 1037364307 vs. 1037364397. I was examining WinOLS hexdumps and also dumped all bins to text file and compared three hexdumps as text one beside the other.
My view of EDC15C2 bin through 8-bit and 16-bit dumps
00000000 - 00007FF0 : empty markers (0xC3C3), this is also a good indicator to spot in the map area - you know it is not part of the map :)
00008000 - 0000FFFF : some executable code, no differences, most certainly some static executable code that is never(?) changed, could be bootloader that CPU uses, or some other auxiliary code.
00010000 - 00013FFF : some differences start to appear, looks like some kind of address table for CPU. 16-bit or 32-bit addresses come to mind, low at start, gradually increasing, no constant difference.
Last few words are checksum of this section - something(?)
00014000 - 00016FFF : differences in some lines, looks like executable data
00017000 - 00019FFF : 99% differences, looks like executable data
0001A000 - 0001A400 : 1 % differences, looks like executable data
0001A400 - 0005FFFF : 100% difference (ignoring padding with 0xC3C3 at the end). This is likely our executable code that is different among software versions. Almost every byte in this region is different from map to map. What backups up my theory about software versions is the fact that for each bin file compared, length of this region is different (when ignoring 0xC3C3 at the end of this region) - changes in software sources were made. So:
- 1037353776 ends at 00055420
- 1037364307 ends at 000575c0
- 1037364397 ends at 00058b80
I can see some pattern here ;) Each newer software version version has few bytes larger executable payload what would explain that somethings need fixing / adding / changing in later versions.
Lets try to correlate HW versions to see if we have some chronological order there, too:
- Code: Select all
SW -- HW
1037353776 -- 0281010877
1037364307 -- 0281010876
1037364397 -- 0281011132
Almost... I'm not sure what the hardware version is meant to "version" exactly - ECU electronics / chips / PCB?
Last few words are checksum of this section - something(?)
00060000 - 0006FFFF : First map area. This what we are here for. Data here is more or less different, except for axis values nad maybe some other things (maps?). For example near address 00061300 all bins have a same set of data 9x9 - what appears to be a map. Changes in the software also affected offsets in map area. This could be due to new map, axis, switch, etc. data was added / removed to / from the map area. Minor differences in map values itself might be caused by the factory reconfiguration / tunning of the ECU after software was updated. Signature byte differences are interesting, too:
- Code: Select all
SW -- RPM IQ 1 IQ 2 ???
1037353776 -- 50222 50826 50850 53248
1037364307 -- 50232 50834 50856 53248
1037364397 -- 50242 50840 50864 53248
Signature Byte seem to follow some kind of a pattern in terms of offsets, eg. offset among bins for a given S.B seems to be constant: RPM = 10, IQ1 = 6, IQ2 = 6, .. others need checking..
It would be interesting to see if there could be same S.B. value for different axis in two different bins :?:
But, I spotted this strange S.B. 53248 (if that is what it is :?:) in all three bins, two occurrences one on each map area start ..
00070000 - 0007FFFF : Second map area. Why do we have two map areas? Redundancy maybe?
There are some differences between the first and this map area - first has SVBLs between SOI and Injection Duration, the other has Pilot Injection map.
I this makes some sense.. feel free to correct me where I'm wrong :)
