I've learned some interesting things trying to map the last few hundred parameters...
What I thought was the ecm part number is actually the part number of the calibration. It does not appear as though the ecm itself was ever changed. Another, very interesting thing... the binary in the winOLS map pack and the binary that I know works, they are the same part number. The binary in the winols map pack was extracted from a truck and came with all the fault tables, injector calibrations, etc. The binary in WinOLS and the binary that works are also assembled slightly differently.
I'm guessing here, but this must have to do with either instructions or flags in the binary to signal the end of a block.
Think of the ecm like the industrial area of your town. A block of addresses might be where all the lumber is stored, another block is where all the steel is stored, another where the machine shops are. Well the memory of the ecm is like that too, the parameters and program are stored in blocks. When the ecm is flashed, the tool must install the xcal or the binary to the correct addresses or the ecm will not work. In terms of binarys, I don't understand how these blocks are identified. In the oem calibrations, due to the way intel hex files are written, the block addresses are clear as daylight.
In our trucks there are four address blocks. One really big one that contains the vast majority of the parameters and three smaller ones. The last few hundred itns are in the last block. In winols, and its map pack the addresses are applied to the bytes sequentially starting from 0x00 (0). With intel hex, all the bytes are broken down into records. The record contains its starting address, the number of bytes in that record, the type of record it is and the checksum for that record. This means that the with an intelhex file, the physical address that byte is going to occupy in the microcontroller is specified. The calibration starts at 0x80020000 (2147614720), so that offset is easy. Add the starting offset to the address and you have the correct location. However, the block I'm working in has a different starting address, but there is an unknown number of extra bytes included that tells... something.... something... and I haven't got a clue what they are, what they do... thus my guess at their purpose. This means that even with the correct starting address for that block, there is an additional shift of bytes I haven't figured out how to calculate yet.
I'm thinking these last few hundred will be easier to figure out manually than to try and program something to find the offsets.
School goes to full speed tomorrow and I'll be lucky to get an hour or two a week on this project for the next three months. I'll keep you updated!