We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
I'm using a custom program to calculate the checksum of the .bin file produced by my uVision build, and to store the checksum value as a #define in a header file used by one of my modules. The project is configured to run this as a user program after build/rebuild. So when I rebuild again, uVision sees that the header file has changed and recompiles/links the affected module(s), so that the new checksum is included in the image, allowing the firmware to verify its own checksum at run-time.
This scheme worked fine until I upgraded from uVision 4.2 to 4.7.2. I now find that although the header file is updated with the new checksum, the next re-build doesn't see the change and build the dependent module(s).
I notice that the modification time on the header file is earlier than the .hex/.bin files, despite the custom program being run (supposedly) after the build. Could that be the cause? The affected module's .o file is older than the header, though, so I would have expected it to be re-compiled. Maybe uVision's dependencies don't work that way. If I 'touch' the header file and rebuild, the module(s) including the header are recompiled correctly.
Is this a known problem?
Thanks
I'm using a custom program to calculate the checksum of the .bin file produced by my uVision build, and to store the checksum value as a #define in a header file used by one of my modules.
This introduces a cyclic dependency into your build system. Strictly speaking, your program would never, ever finish building, because there's always at least one file that's newer than one the files built from it.
In a sense, Keil is actually doing you a favour by breaking this vicious circle.
I suggest you abandon this plan and replace it by what virtually everyone else does: patch the reference checksum directly into the binary (or more typically: the hex file).