Apply Luhn algorithm on flash functionality

CRC16 is better, as with Luhn two wrong numbers could still create a good checksum

http://en.wikipedia.org/wiki/Cyclic_redundancy_check

http://www.ti.com/lit/an/slaa221/slaa221.pdf

Oh cool! Seems a good article to investigate on! Thanks!

A base-10 checksum is a non-obvious match for a (base-256) flash.

Phil Koopman at CMU has done some very impressive research into CRCs. Among his results: (1) The polynomial makes a big difference (2) Many of the common CRCs (CCITT-16, CRC-16 (2 flavors) et al) are not very good. One of his papers has a table of CRC polynomials with measurements of their actual effectiveness (multiple criteria). If you don't have to match a standard, I suggest you pick one from his table.

For cheapskates like me, he has also analyzed a number of (computationally simpler) checksums. Here again, small algorithm differences make a big difference, and more-complex is not necessarily better.

Some of the compiler/linker will generate CRC (or other checksum) and include that in the Flash image. Some of the MSP430 chips have CRC module.

Also Flash Marginal Read option can detect Flash defects before they show up in normal Read.

These guidelines should serve as a starting point for making informed design choices:

. Never use an XOR checksum when it is possible to
  use a two’s complement addition checksum (or
  something even better).

. Use a one’s complement addition checksum in
  preference to a two’s complement addition checksum
  for random independent bit errors.

. Use a two’s complement addition checksum in
  preference to a one’s complement addition checksum
  for burst errors. If both burst and random independent
  bit errors matter, one’s complement is probably
  the better choice.

. If computational resources are available, use a
  Fletcher checksum in preference to one’s complement
  or two’s complement addition checksums to
  protect against random independent bit errors. Do
  not use a Fletcher checksum if burst errors are the
  dominant fault expected and data consists predominantly
  of continuous strings of all zeros or all ones.

. If computational resources are available, use a CRC
  instead of any of the other checksums mentioned. It
  is generally better for both random independent bit
  errors and burst errors.

old_cow_yellow said:

Some of the compiler/linker will generate CRC (or other checksum) and include that in the Flash image. Some of the MSP430 chips have CRC module.

Also Flash Marginal Read option can detect Flash defects before they show up in normal Read.

Meaning that I do not need to use a check-sum to get the errors then?

Cool Tony! Thanks!

Bruce McKenney47378 said:

A base-10 checksum is a non-obvious match for a (base-256) flash.

Phil Koopman at CMU has done some very impressive research into CRCs. Among his results: (1) The polynomial makes a big difference (2) Many of the common CRCs (CCITT-16, CRC-16 (2 flavors) et al) are not very good. One of his papers has a table of CRC polynomials with measurements of their actual effectiveness (multiple criteria). If you don't have to match a standard, I suggest you pick one from his table.

For cheapskates like me, he has also analyzed a number of (computationally simpler) checksums. Here again, small algorithm differences make a big difference, and more-complex is not necessarily better.

Oh, then you do not recommend CRC! 

CaEngineer said:

Also Flash Marginal Read option can detect Flash defects before they show up in normal Read.