Advin Programmer Logo

Universal Programmer,
EPROM Programmer


Programmers Home Programmer Adapter IC Programming Services.jpg How to do EPROM Programming

Best Practices for EPROM IC Chip Programming
(5) Making Good Use of Checksums
Back to Best Practices ...

(A) Naming a data file

When you name a data file, it is a good idea to embed the checksum as a part of the filename. For example:
    PN3051-CS=1234.hex

When you or your operator load the data file a month from now, if the s/w displays a different checksum than 1234, then you know something may be wrong.

For example, if you load the above file by mistake as a binary file, then the checksum would not agree. Or if you selected a device with a different memory size, then the checksum would also not match.

(B) Labeling an IC Chip

It is a good idea to put the checksum as a part of the label. For example:
    PN3051
    CS=1234

When you give this IC chip to someone to make copies, if he sees the same checksum after he read the chip with his programmer, then he has a certain level of confidence that the programming equipment is good.
Many years later, if you need to make copies off this chip and you see a matching checksum, then you also have confidence that the data inside the chip is intact.

(C) How Checksum is Calculated

For memory devices, the most common and conventional method is adding all the bytes up and accumulate the sum in a 16-bit word (which is 2 bytes or 4 hex digits). Any overflow (5th digit and up) will be thrown away. Newer programmers may accumulate the sum in 4 bytes, meaning 8 digits. The 8 digits look impressive but actually do not serve much additional purpose. It is cumbersome to read by a human being and a lot of people just use the lower 4 digits.

(D) How Useful are Checksums?

Use of checksums give you certain levels of confidence that things are right. But it is not an absolute proof that everything is right.

A small business owner is doing manual payroll for his 5 employees. He adds up this week's 5 paychecks and the total is the same as last weeks (i.e. the sums match). So he knows he did not write any checks that are off by a digit. If the sum of payment is different from last week's (assuming no pay increase or cut), it gives him an immediate alarm that something is not right.

However, if he swapped two employee's pay, his checksum would still be the same and the alarm is not sounded.

The use of checksum is similar. If bytes are swapped around, the checksum still remains the same.

(E) Problems that Cannot be Caught by Looking at Checksums Alone

Fortunately, these problems do not occur very often. They are mentioned here for your curiosity only.

(i) When odd and even bytes are swapped, as in the case of programming a byte-wide EPROM for an Intel versus a Motorola microcontroller.

(ii) You have a data file that does not occupy the complete EPROM. When you load the data file, you shifted the data down by, say, 100 bytes due to a previous setting leftover by someone who used the programmer last night. Then instead of having all unused bytes at the end of the EPROM, you now have some 100 blank bytes at the beginning of the EPROM. In this case, all the bytes are the same but they are shifted.

(F) Problems that Can be Caught by Looking at Checksums

(i) The most important use of checksum is for alerting data deterioation.

If you know that the checksum of a certain EPROM chip in a machine made 20 years ago is, say, 1234, and when you read it now, it has a different checksum, then you are almost certain that there is a loss of data. It is especially true if the checksum is not consistent every time you read from the chip.

The cause of EPROM cells losing data (i.e. losing captive charge) can be caused by many factors, such as inappropriate voltage or pulse length when it was programmed in the first place. Or the label is not opaque, if the EPROM chip has a quartz window. Or due to static damage. Or simply the ability of a particular brand of chip to hold data has elapsed.

Because of this usefulness, it is advisable to put the checksum on the label of an EPROM chip if space is available.

(ii) The other use of checksum is to help catching simple human errors such as selecting the wrong data file, the wrong device, or the wrong settings. On the other hand, matching checksum is not a proof, but it does give certain levels of confidence of the positive.


Back to Best Practices for EPROM Programming

Sales email:    Sales@Advin.com
Support email:   Support@Advin.com
1-408-243-7000
Office hours: 8AM to 5PM, California Time.