How is the checksum for EEC-V calculated?

[DWS]

EDIT: I worked out what I had wrong, see my next post below for what I found.





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).

Next, 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.

Another point in the same docuemtn

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

0x200A seems like it must be the right address, at least for the CRA* Strategies.

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.

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.

[DWS]

Welp, I got it figured out, lots of poking around but the logic in my mind was right. I reworked my code and I might have had a mistake in there somewhere, rebuilt it, added the address ranges and all is good now.

If anyone was wondering here's the address ranges to add together (add as 16 bit words ignoring overflow) aka FFFF + FFFF = FFFE. Order is little endian, so be sure to process the numbers correctly or it won't carry correctly.

EEC-V 216k

Bank 0 - 0x2000-0xFFFF len: 0xE000
Bank 1 - 0x2000-0xDFFF len: 0xC000
Bank 8 - 0x2000-0xFFFF len: 0xE000
Bank 9 - 0x2000-0xFDFF len: 0xDF00 (last 0xFF bytes ignored in checksum)

FYI, I'm using the addresses as they are referenced in the code, aka 0x0000-0x1FFF isn't part of the dumps, some files start at 0x2000.

Worth a note that the end of Bank 9 address 0xFE00-0xFFFF is not validated, but it mostly contains text for reference anyway.

For the actual math, once all of the words are added together, you perform the two's complement on the value which gives you the check sum to add at Bank 1 address 0x2004 and/or 0x200A (spec says to use 0x200A). When adding the values, you should skip the checksum address or fill with 0x0000 first.

Probably not the best guide in the world, but it's something that should be public in my opinion. Of course it might not work for all files, I did have some come back as 0x0020 for some reason (several files, not just one), not super sure why but I'll have to investigate that later. Sanity check, PCM Flash says the one file I tested with the checksum coming back as 0x0020 does have the correct checksum. Most of the files came back 0x0000, so mostly a success =).

[DWS]

Found another pattern, looks like early eec-v 4 bank computers had a smaller bank 1 than the later ones. Checksum is done in the same way, but just a different address size for bank 1. Checksum appears to be still stored at bank 1 0x200A

EEC-V 216k (bank 1 treated as 0x8000 long starting at 0x2000).

Bank 0 - 0x2000-0xFFFF len: 0xE000
Bank 1 - 0x2000-0x9FFF len: 0x8000
Bank 8 - 0x2000-0xFFFF len: 0xE000
Bank 9 - 0x2000-0xFDFF len: 0xDF00 (last 0xFF bytes ignored in checksum)

Which variation seems to be purely based on strategy, even if the individual file has just padding in the extra space. Seems like the best route to test is to calculate both versions vs a stock unmodified bin, then treat all files of the same strategy as that variation.

Edit: I tested this theory out, it does seem to match up, at least for the stock bins I have collected so far, aka ignore the contents in the file and use a lookup table for which variation of the checksum function is used, if unknown, process the file in check mode (add all addresses up, should get 0x0000), whichever one validates should be the correct version for all files with the same strategy.

[In-Tech]

Hiya,
I am not a Ford guy, but have dabbled. Here is some more weirdness you might run across.

Code: Select all

"Normal" 216K EECV
CK_Bank0	Bank 0	0x02000	0x0FFFE	0xE000
CK_Bank8	Bank 8	0x82000	0x8FFFE	0xE000
CK_Bank9	Bank 9	0x92000	0x9FEFE	0xE000
CK_Bank1	Bank 1	0x12000	0x1DFFE	0xC000

“ALAPK” and others I bet.  216K Checksum

CK_Bank0	Bank 0	0x02000	0x0FFFE	0xE000
CK_Bank8	Bank 8	0x82000	0x8FFFE	0xE000
CK_Bank9	Bank 9	0x92000	0x9FEFE	0xE000
CK_Bank1	Bank 1	0x12000	0x19FFE	0x8000

[DWS]

Yea that's basically exactly what I ran into, except it looks like your ending addresses all end in E instead of F? Is that the difference you've noticed, or maybe just how the software uses the ending address.

Also, my findings on ALAPK is the same, it's the smaller checksum length. I probably should add the lengths to the tables I posted.

Thanks for confirming though. I'm working on a website to edit bins, so fixing the checksum automatically would make sense =). Also would be neat to pass/fail the check sum of the uploaded file, if failed, notify the user encase it should be a pass.

I'm seeing roughly 33% with bank 1 length 0x8000 for the checksum. The percent is based on unique strategy files.

I haven't dove into the EEC-IV computers much yet (1 bank and 2 bank), but I suspect their checksums are done in a similar way. My bank auto detect code doesn't work with them though, I got some restructuring to do to in the code.

I'm wondering if there's any pattern to detect between those two variations, I suspect there must be something that's easy to pick up on, I doubt Ford's software would have to do a strategy look up to validate which checksum to perform.