Which version of Dynamic C? In Dynamic C 10, it should be possible to get repeatable builds. You might be seeing changes in the build timestamp, which you can override by setting FIRMWARE_TIMESTAMP in your Project macros.
Take a look at Samples/firmware_info.c to dump the contents of the firmware_info_t data structure embedded at the start of the .bin file.
If you use the DATE or TIME macros in your program, you’ll see variations in the .bin file as well.
If the build timestamp changes, you’ll also see a change in the CRC32 of the firmware_info_t structure, and a CRC32 at the end of the .bin file.
Dynamic C 9 and earlier also embed a build time in the binary file (as dc_timestamp), but don’t provide a method to override it with a fixed value.
Thank you for the answer!
The location of the firmware_info_t in the binary file is still not clear, but of no importance! A description of the binary file format would be helpful.
Also i do not know how long the generated header in the binary file is!
Also the CRC (if any) at the end of the binary file is not changed.
Basically I have enough information to describe in a procedure how to compare binary files and make sure they have been generated with the same source files.
Thank you!
Note that firmware_info_t is only present in Dynamic C 10 binaries (sometime after the 10.40 release). The fact that the last four bytes of the .bin file don’t change leads me to believe that you’re using Dynamic C 9 or earlier.
The binary file contains data that RFU (Rabbit Field Utility) will write to the flash memory of the Rabbit hardware. It contains your compiled program and constants. You can look at the .MAP file to understand what’s placed at various offsets, and the .LST file will also give you some insight to what’s in there. The start of the file holds the BIOS – code to bring the hardware up before calling your main().
The area immediately before or after that timestamp might be the “prog_param” structure. You can run Samples/SEEPARAM.C to get a dump of that structure’s contents. Some of it rarely changes, so you could search for a specific byte sequence from that structure to identify the offset of the timestamp (which should be the number of seconds since 1/1/1980).