Orig Post:
Either I'm doing something very wrong, or my understanding of what should be happening isn't accurate. Can anyone validate the process to generate a checksum for these computers?
Of my understanding, you add each word (2 bytes) of data for the whole addressable block and calculate the 2's compliment while ignoring all overflows.
On the validation side, it should end up where when you add all of the values together including the checksum address you should end up with 0x0000 and any other value is a failed checksum.
My source file is a stock bin, PCMFlash confirms the checksum is valid in the file, yet when I attempt to calculate it, I don't get anything even remotely close (I'm adding them up including the check sum so expected output should be 0x0000).
I also found some public XDF's that confirm what I'm trying to do as far as the address range (0x2000-0xDFFF) and check sum stored at 0x200A. I tried to use the XDF to generate the check sum and it also generates a different value than expected. All documentation around this subject seems to be really vague and no solid details are given.
This is from the Ford docuementation I found on a different strategy (CRAI8), again no hard addresses are given, sounds like just the whole address range is ran (assuming 0x2000-0xDFFF as before 0x2000 isn't part of the bin dumps).
Another point in the same docuemtnNext, a 16 bit addition of the contents of the ROM locations is performed. A parameter (ROM_TO) is set to a value that should
cause the result of the summation to be zero. If the value is not zero, then some value in ROM has been corrupted. (Note,
during development, the use of patched chips, RCONs, etc. can cause this test to fail.) If a failure is detected, Code P0605 is
set and Self Test continues.
0x200A seems like it must be the right address, at least for the CRA* Strategies.38.1.2.4 Kam_rom_test
void kam_rom_test()
BEGIN_FUNC /* BEGIN: kam_rom_test */
IF (UNCONDITIONALLY)
THEN NO_ACTION; /* After register test, perform a */
/* 16 bit (word) addition of contents */
/* of all ROM locations retaining the */
/* 16 least significant bits of the */
/* result. */
/* Note: The parameter ROM_TO contains */
/* a checksum such that the sum of the */
/* ROM contents will equal zero. */
END_IF
I don't normally work with checksums, so it's not my normal thing. PCMFlash does correct this for me, but I want to calculate it when I do modifications so the checksum comes back as valid which tells me the file isn't corrupt etc.For 1988 and beyond, the procedure has been changed to make this process
easier. The new process removes CALID and replaces it with ROM_TO. In
addition, VERID has been deleted and a new parameter "FIXSUM" has been added.
FIXSUM should always be set to 0. Specifically:
1. The non-modifiable Vector parameter "ROM_TO" replaces the old CALID
parameter as the ROM chip identifier. The ROM_TO value is generated by
Vector during a calibration release and is located at 200A HEX. This
value is the complement of the ROM pattern CHECKSUM and is also used to
perform the EEC-IV diagnostic "CHECKSUM Memory Test".
2. The new parameter "FIXSUM" is a Vector calibration parameter located at
2004 HEX and should always be set to 0. This parameter will be used to
assure the ROM_TO values are unique and will only be changed by the SWDV
engineer if a duplicate ROM_TO value is found.