Skip to main content

IAR Embedded Workbench for RL78 5.20

Briefly about checksum calculation

In this section:

You can use a checksum to verify that the image is the same at runtime as when the image’s original checksum was generated. In other words, to verify that the image has not been corrupted.

This works as follows:

  • You need an initial checksum.

    You can either use the IAR ELF Tool—ielftool—to generate an initial checksum or you might have a third-party checksum available.

  • You must generate a second checksum during runtime.

    You can either add specific code to your application source code for calculating a checksum during runtime or you can use some dedicated hardware on your device for calculating a checksum during runtime.

  • You must add specific code to your application source code for comparing the two checksums and take an appropriate action if they differ.

    If the two checksums have been calculated in the same way, and if there are no errors in the image, the checksums should be identical. If not, you should first suspect that the two checksums were not generated in the same way.

No matter which solutions you use for generating the two checksum, you must make sure that both checksums are calculated in the exact same way. If you use ielftool for the initial checksum and use a software-based calculation during runtime, you have full control of the generation for both checksums. However, if you are using a third-party checksum for the initial checksum or some hardware support for the checksum calculation during runtime, there might be additional requirements that you must consider.

For the two checksums, there are some choices that you must always consider and there are some choices to make only if there are additional requirements. Still, all of the details must be the same for both checksums.

Always consider:

  • Checksum range

    The memory range (or ranges) that you want to verify by means of checksums. Typically, you might want to calculate a checksum for all ROM memory. However, you might want to calculate a checksum only for specific ranges. Remember that:

    • It is OK to have several ranges for one checksum.

    • The checksum must be calculated from the lowest to the highest address for every memory range.

    • Each memory range must be verified in the same order as defined, for example, 0x100–0x1FF,0x400–0x4FF is not the same as 0x400–0x4FF,0x100–0x1FF.

    • If several checksums are used, you should place them in sections with unique names and use unique symbol names.

    • A checksum should never be calculated on a memory range that contains a checksum or a software breakpoint.

  • Algorithm and size of checksum

    You should consider which algorithm is most suitable in your case. There are two basic choices, Sum—a simple arithmetic algorithm—or CRC—which is the most commonly used algorithm. For CRC there are different sizes to choose for the checksum, 2,4, or 8 bytes where the predefined polynomials are wide enough to suit the size, for more error detecting power. The predefined polynomials work well for most, but possibly not for all data sets. If not, you can specify your own polynomial. If you just want a decent error detecting mechanism, use the predefined CRC algorithm for your checksum size, typically CRC16 or CRC32.

    Note: For an n-bit polynomial, the n:th bit is always considered to be set. For a 16-bit polynomial—for example, CRC16—this means that 0x11021 is the same as 0x1021.

    For more information about selecting an appropriate polynomial for data sets with non-uniform distribution, see for example section 3.5.3 in Tannenbaum, A.S., Computer Networks, Prentice Hall 1981, ISBN: 0131646990.

  • Fill

    Every byte in the checksum range must have a well-defined value before the checksum can be calculated. Typically, bytes with unknown values are pad bytes that have been added for alignment. This means that you must specify which fill pattern to be used during calculation, typically 0xFF or 0x00.

  • Initial value

    The checksum must always have an explicit initial value.

In addition to these mandatory details, there might be other details to consider. Typically, this might happen when you have a third-party checksum, you want the checksum be compliant with the Rocksoft™ checksum model, or when you use hardware support for generating a checksum during runtime. ielftool also provides support for controlling alignment, complement, bit order, byte order within words, and checksum unit size.