Keithley 2001 CAL EEPROM: how to calculate the checksum?

[Le_Bassiste]

i accidentially screwed the contents of the CAL EEPROM in a KEI2001 while attempting a "brain transplant" (i.e., exchanging the single-rom digital board with a dual-rom version).
however, i have all cal constants available from a previous GPIB dump, and i have them also available in the required IEEE format. i can re-program the EEPROM with those values via a TL866, but i'm struggling to figure out the correct way to calculate the checksum over the hundred cal constants. TiN's article about the way to calculate it left me puzzled, to say the least.
would be great, if somebody could give me an example of how to do that properly, ELI5-style.

[macboy]

If you would link to "TiN's article" that you refer to, that would be very helpful indeed. Don't expect people to do that extra legwork when you are asking for their help.

[Le_Bassiste]

If you would link to "TiN's article" that you refer to, that would be very helpful indeed.

yep, point taken. here it is: https://xdevs.com/fix/kei2001/, section "Calibration decode for EEPROM contents", especially the remark in the table, "16-bit summator of cal values 0×18 – 0×108 , rotated byte by 4", which i don't understand.

Don't expect people to do that extra legwork when you are asking for their help.

just for clarification, i'm not expecting anybody to help me, nor to do any "legwork" for me.  i'm asking for help. big difference. 
if that's presenting an insult to you, my apologies. 

[Kleinstein]

As I understand it the roted byte by 4 means shifting the bits 4 to one side with roll over. With 4 shifts  the direction of the shifts does no matter. A different way to describe is is swapping the lower and upper 4 bits in each byte (likely done to better catch a problem like a bad data line). I think the sum as 16 bit numbers should be relatively clear.

[Le_Bassiste]

thanks kleinstein, tried that:
i've pulled the cal data in the range 0x18 to 0x108 from a working data set as follows:

Code: [Select]

3FF0014B041616F3
3F2A5D4FB38842F1
4024041A6320BB9A
3F2B04CD5DCE72F1
3FF0002564D567E4
3F0DF0C59D100BC3
402402A75A1BE7E1
3F1F5A705E6BA5E2
4058FFBC920EDC9B
407F0466AC3C8EC4
3F6D1AE86447A000
3F70A1A95DDFC800
3F58F27E0CCFA000
3F6D1AE86447A000
3F70A1A95DDFC800
4060800000000000
4061200000000000
0
3FF0000000000000
3FF0000000000000
3FF0013A92A30553
3FF000D1B71758E2
3FB999999999999A
3FF0000000000000
4060000000000000
4060800000000000
4060800000000000
4061200000000000
0
0
0

after a 4-byte rotate, that would give the following 16-bit summands:

Code: [Select]

014B
5D4F
041A
04CD
0025
F0C5
02A7
5A70
FFBC
0466
1AE8
A1A9
F27E
1AE8
A1A9
8000
2000
0000
0000
0000
013A
00D1
9999
0000
0000
8000
8000
2000
0000
0000
0000

summing them all up into one 16 bit value gives 80E8. however, the checksum in the EEPROM at 0x110 reads B7CD.
what am i missing?

[Kleinstein]

I think the describtion is more like to first separate the data to 16 bit chunk, than do the sum (ignoring overflow)  and only finally do a 4 bit shift / nibble swapping for the 2 byte sum.

[Renate]

I get 0xb7fd.

[Le_Bassiste]

I think the describtion is more like to first separate the data to 16 bit chunk, than do the sum (ignoring overflow)  and only finally do a 4 bit shift / nibble swapping for the 2 byte sum.

sounds reasonable, but it's not clear to me where you got the 4 bit shift rule from in TiN's description.
anyway, sum of all 16 bit chunks (w/o any further bit shifting, truncated to 16 bits) results in 7FDB. still not correct

[TiN]

Sounds like an Xmas horror story. 

On topic - I don't remember, but most likely big endian conversion involved and _probably_ rotate by 4 was meant to be swap the nibbles around .

[fzabkar]

I get 0xb7fd.

I get the same.

I have written a checksum tool that might help.

http://www.users.on.net/~fzabkar/temp/checksum.exe
http://www.users.on.net/~fzabkar/temp/checksum.bas

[mikerj]

I think the describtion is more like to first separate the data to 16 bit chunk, than do the sum (ignoring overflow)  and only finally do a 4 bit shift / nibble swapping for the 2 byte sum.

sounds reasonable, but it's not clear to me where you got the 4 bit shift rule from in TiN's description.
anyway, sum of all 16 bit chunks (w/o any further bit shifting, truncated to 16 bits) results in 7FDB. still not correct

Apply the 4 bit shift to your result and you get the same B7FD which others have calculated.

[Le_Bassiste]

mikerj, got that. however, for the given dataset, my KEI2001 decided the correct checksum to be B7CD, not B7FD

[Le_Bassiste]

Sounds like an Xmas horror story. 

On topic - I don't remember, but most likely big endian conversion involved and _probably_ rotate by 4 was meant to be swap the nibbles around .

ah, missed the big endian. will try that!
by the way, that poor franken-thingy is a well known ex-patient of yours.