Hi,
I have been trying to implement a checksum on an ARM9 using the RealView Armcc compiler. To place my checksum at the proper location, I use:
#define INTEGRITY_COMPARE_VAL_ADDR 0x1006FFFF #define INTEGRITY_COMPARE_VAL 0x12345678 const volatile unsigned char integrity_compare_val __attribute__((at(INTEGRITY_COMPARE_VAL_ADDR))) = INTEGRITY_COMPARE_VAL;
At startup, I compute the checksum over all memory from 0x10000000 to 0x1000FFFE. My naive approach was to then set the definition of INTEGRITY_COMPARE_VAL to this checksum, recompile, then run successfully. While this works occasionally, by performing diffs of the generated hex files, I've found that changing the INTEGRITY_COMPARE_VAL (and really the value at the location of variable integrity_compare_val), the hex file differs at more locations than just the one expected spot. The other differences don't appear to be tied to the compare value explicitly since "12345678" only occurs once in the hex files and at the proper location. Is there a compiler option I'm missing or is this expected behavior? I have optimization at level 0.
I have looked at Keil's appnote on using the CHECK8 utilitiy (http://www.keil.com/support/docs/494.htm) to sign the hex file but was avoiding this approach since we may want to move onto a more robust signing procedure (32-bit checksum, CRC-16, MD5, etc.) in the future. In addition, CHECK8 doesn't want to run on Windows 7 64-bit. On past projects, I've taken the external signing (like CHECK8) approach, but on those platforms had a tool to create a hex file that covered the entire memory space, making custom checksums much easier.
Would appreciate any tips or advice.
Thank you, Louis
Fixed flash contents would be fine. Is there a directive or a syntax trick to get that? I was hoping that "const" would do that, but I guess not based on the changing values elsewhere.
Sorry about the confusing memory locations. I copypasted my code in between a changeover from 32-bit to 8-bit checksum and failed to fix. The processor is an AT91SAM9263 with an 0x0007_0000 long Flash memory starting at 0x1000_0000. I'd prefer to create a 32-bit checksum (would go with 8-bit if have to use Keil's tools) so the code memory would be from 0x1000_0000 to 0x1006_FFF8 and position the checksum at 0x1006_FFFC.