This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

[MDK412] Automatic checksum calculation and insertion

I've downloaded the evaluation versin of uVision 4 and wondering if it is suitable for a project that we will be starting soon.

The SRS of the project states that the application must be broken into two parts:
Bootloader(8K Max)
Application(56K Max)

The boot loader must calculate the CRC32 of itself, then the application, and fall into fail safe if the checksum is incorrect.

Can the linker calculate the CRC32 and place the result in the destination executable? Or is there another application that can take the resulting file and calculate the checksum?

Parents
  • For download files, I normally have a header at the start, to allow the boot loader to spit and complain instantly if someone tries to send a binary that is intended for a different hardware platform, or to warn about potential incompatible downgrades etc.

    For stored binary, I normally have a block at the end, which allows the start to begin with an interrupt table or similar. If the memory architecture of the platform is complicated, I may store an index to extra information at a fixed location somewhere in the early part of the binary - for example directly after the last interrupt vector.

    One thing with a CRC stored at the end of a memory block is that I can have the boot loader compute the CRC for the full block and expect it to end up with the value 0. This is a bit simpler than computing the CRC for everything but the CRC and then compare with the stored CRC.

    I normally do want all bytes checksummed, even if there are unused parts of the flash. If they suddenly changes contents then either the program has a bug trigging IAP flash overwrites, or there is something wrong with the flash (maybe device running at too high temperatures) and more bits are likely to fail soon.

Reply
  • For download files, I normally have a header at the start, to allow the boot loader to spit and complain instantly if someone tries to send a binary that is intended for a different hardware platform, or to warn about potential incompatible downgrades etc.

    For stored binary, I normally have a block at the end, which allows the start to begin with an interrupt table or similar. If the memory architecture of the platform is complicated, I may store an index to extra information at a fixed location somewhere in the early part of the binary - for example directly after the last interrupt vector.

    One thing with a CRC stored at the end of a memory block is that I can have the boot loader compute the CRC for the full block and expect it to end up with the value 0. This is a bit simpler than computing the CRC for everything but the CRC and then compare with the stored CRC.

    I normally do want all bytes checksummed, even if there are unused parts of the flash. If they suddenly changes contents then either the program has a bug trigging IAP flash overwrites, or there is something wrong with the flash (maybe device running at too high temperatures) and more bits are likely to fail soon.

Children
No data