What is the file format of the binary files generated by Dynamic C?
Is the file format documented somewhere ?
The question arises because I want to compare bin files to make sure if they have been built with same version (source code) of the software.
For each build of the SW the binary files are different in the first up to ~132 bytes (onyl a few bytes are different).
It is not clear what causes the differences? (is it any time information of the build?)
Is it possible to suppress these differences?
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.
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).