Keithley 2001 CAL EEPROM: how to calculate the checksum? - Page 1
Forum section: electronics / repair

author: Le_Bassiste
author_rank: Frequent Contributor
timestamp: December 03, 2019, 02:01:44 pm
content: 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.

author: macboy
author_rank: Super Contributor
timestamp: December 03, 2019, 05:13:39 pm
content: 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.

author: Le_Bassiste
author_rank: Frequent Contributor
timestamp: December 03, 2019, 09:28:46 pm
content: Quote from: macboy on December 03, 2019, 05:13:39 pmyep, 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.Quote from: macboy on December 03, 2019, 05:13:39 pmjust for clarification, i'm notexpectinganybody to help me, nor to do any "legwork" for me. i'maskingfor help. big difference.if that's presenting an insult to you, my apologies.

author: Kleinstein
author_rank: Super Contributor
timestamp: December 03, 2019, 09:59:41 pm
content: 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.

author: Le_Bassiste
author_rank: Frequent Contributor
timestamp: December 04, 2019, 11:54:25 am
content: thanks kleinstein, tried that:i've pulled the cal data in the range 0x18 to 0x108 from a working data set as follows:Code:3FF0014B041616F33F2A5D4FB38842F14024041A6320BB9A3F2B04CD5DCE72F13FF0002564D567E43F0DF0C59D100BC3402402A75A1BE7E13F1F5A705E6BA5E24058FFBC920EDC9B407F0466AC3C8EC43F6D1AE86447A0003F70A1A95DDFC8003F58F27E0CCFA0003F6D1AE86447A0003F70A1A95DDFC8004060800000000000406120000000000003FF00000000000003FF00000000000003FF0013A92A305533FF000D1B71758E23FB999999999999A3FF00000000000004060000000000000406080000000000040608000000000004061200000000000000after a 4-byte rotate, that would give the following 16-bit summands:Code:014B5D4F041A04CD0025F0C502A75A70FFBC04661AE8A1A9F27E1AE8A1A980002000000000000000013A00D1999900000000800080002000000000000000summing them all up into one 16 bit value gives 80E8. however, the checksum in the EEPROM at 0x110 reads B7CD.what am i missing?

author: Kleinstein
author_rank: Super Contributor
timestamp: December 04, 2019, 05:15:31 pm
content: 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.

author: Renate
author_rank: Super Contributor
timestamp: December 04, 2019, 10:30:43 pm
content: I get 0xb7fd.

author: Le_Bassiste
author_rank: Frequent Contributor
timestamp: December 04, 2019, 11:33:21 pm
content: Quote from: Kleinstein on December 04, 2019, 05:15:31 pmsounds 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

author: TiN
author_rank: Super Contributor
timestamp: December 04, 2019, 11:53:36 pm
content: 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 .

author: fzabkar
author_rank: Super Contributor
timestamp: December 05, 2019, 12:41:10 am
content: Quote from: Renate on December 04, 2019, 10:30:43 pmI get the same.I have written a checksum tool that might help.http://www.users.on.net/~fzabkar/temp/checksum.exehttp://www.users.on.net/~fzabkar/temp/checksum.bas

author: mikerj
author_rank: Super Contributor
timestamp: December 05, 2019, 01:47:08 am
content: Quote from: Le_Bassiste on December 04, 2019, 11:33:21 pmApply the 4 bit shift to your result and you get the same B7FD which others have calculated.

author: Le_Bassiste
author_rank: Frequent Contributor
timestamp: December 05, 2019, 08:12:34 am
content: mikerj, got that. however, for the given dataset, my KEI2001 decided the correct checksum to be B7CD, not B7FD

author: Le_Bassiste
author_rank: Frequent Contributor
timestamp: December 05, 2019, 08:13:55 am
content: Quote from: TiN on December 04, 2019, 11:53:36 pmah, missed the big endian. will try that!by the way, that poor franken-thingy is a well known ex-patient of yours.