Mismatch - .s19 Files

[AlexanderLeenus]

I am using function called "__DATE__" in my code. This build date is basically connected to .S19 file.

When I have repeated the build at later days, and compared the new generated .s19 file with old .s19 file. It is not matching. Obliviously date will not match; I would expect up to 8 bytes (at the location of the global variable used) would fail the compare.

But, when I am compares new .s19 with old .s19, more than 8 bytes (more bytes) are failing the compare. I guess it is based on what those 8 values and compiler is optimizing things differently. 

1. How to get identical .s19 file? (Only [date] 8 bytes exceptional when compare)

2. I am not sure what this __DATE__ function doing while compiling. Is there anything I have to do with compiler optimization in this case?

Or any other way I can solve this issue?

Please Help

Alex

[AlexanderLeenus · Accepted solution]

I have stored the date to global constant variable from local variable in my code. Its looks fine now, only date bytes changes.

[Lundin]

In CW __DATE__ is only changed if you "touch" the file where that macro is expanded. Otherwise the old .obj file will be used.

So you will have to either manually mark the file as changed each time, or you will have to set up some pre-linker script which opens the file and closes it. I remember doing the latter myself for this purpose in an old CW version. I will take a look around and see if I can find out how I did it.

[CrasyCat]

Hello

This one is not specific enough right now.

We need more information.

Can you check which is the address of the bytes, which are different in both .s19 file?

Can you check the MAP file as well and find out which objects (function, constants, ...) are allocated there?

Also are you using __DATE__ directly inside of a function or are you defining a constant, where the date is stored?

If you are using a constant, is this constant defined in the same module where it is used?

CrasyCat

[BlackNight]

Hello,

the __DATE__ preprocessor directive creates a string like "Aug 20 2010" which can be used e.g. to report the compilation date of the file. As CracyCat points out, the .s19 file (or the code binary) will be different depending how this __DATE__ is used. And the linker might have an impact as well where and how the resulting string is allocated.

BK

[CompilerGuru]

>But, when I am compares new .s19 with old .s19, more than 8 bytes (more bytes) are failing the compare.

> I guess it is based on what those 8 values and compiler is optimizing things differently.

__DATE__ is longer than 8 bytes, and also its length may differ when compiled on different dates.

So unless __DATE__ gets assigned into a fixed size buffer, all the subsequently allocated objects will be starting at different addresses too, so this can explain why you end up with many more differences than just the __DATE__ content.

I would suggest to either place __DATE__ into a fixed size (const) buffer, or allocate it specially to an address so it does not affect the rest of the code. Also I would compare the map files and the decoded elf files first before looking at the srecords. Once the map file contain the same addresses for all the functions, the srecords should match up to the __DATE__ content. But when the addresses in the map file differ, then looking into the srecords just shows a lot of differences.

BTW. The decoder can disassemble srecords as well. But as I said, start with comparing the map files, only once they match, looking at the srecord level makes sense (and should not show many differences anymore).

Daniel

[Emac]

One thing to look out for is also the compiler options that allow for inclusion of both the time and the path of the code to be included in the .s19 file.  if you need help finding this option, I will post later.

[Emac]

Be sure to turn of the inclusion of the Timestamp (default is on) by changing the linker properties and adding the following environment variable setting:

-EnvINCLUDETIME=OFF

Edit>[your tool] Settings>Target>Linker for [HC12|HC08]>Command Line Arguments

just add -EnvINCLUDETIME=OFF

This may help in the binary comparison.   All the above comments are correct as well regarding space for the _DATE macro.

My suggestion is to try it first without the date macro, get that to compare consistently, and then work in your _DATE macro