I get two different HEX-files from one project

Go To Last Post
11 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello to everyone,

 

I'm trying to compile a project in Atmel Studio 7.0.1645 for AT32UC3B0256 MCU.

After compiling I get a HEX file. Then I close Atmel Studio, open it, make "Clean project", make "Rebuild project". And get another HEX-file with a difference from the first one.

Even after using avr32-strip utility with "-s" option in all cases.

 

But this is not always the case.

 

Sometimes one file becomes larger than other. But i did not any changes in the project. So how is it possible?

I think compiler creates some debug information in the HEX file or something else. And this information is not deleted from the HEX file. So how can I remove it from HEX-file?

I build project in Release mode, with NODEBUG options.

Maybe there is an additional software in addition to avr32-strip to do this?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well start by diffing the files. That should show if it's just something "bolted on the end". Also load the files into hex editor - is what has changed just "text"? Another approach is to convert them to binary then use the excellent vbindiff to do a visual diff on the binaries. ("objcopy -I ihex -O binary foo.hex foo.bin" will create binaries)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, already done with this using objcopy and a hex viewer.  It is not just a text containing some debug paths/symbols, it is some kind of a clear binary code. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How about the map files - they should tell you what is at the "added" bit.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,

 

just done analyzing the code. Viewing the map file pointed me to different code inside the various user functions. Disassembler shows various constants / addresses in the registers. So it is a clear code that is compiled in a variety of ways! The compilation runs on the Windows 10 x64. After installing the older IDE version Atmel Studio 6.2.1563 sp2 the behavior didn't change (the AVR32 GNU toolchain has the same version 4.4.7).

 

But! After installing Atmel Studio 6.2.1563 sp2 on old PC with Windows XP x32 the compilation results in the same hex every time it is compiled! Absolutely the same project, toolchain and IDE in both cases. The only difference is OS. Apparently Windows 10 x64 somehow makes the toolchain to create the different code from one compilation to another.

 

So the problem fixed but has remained unclear. I just needed a constant hex-file for the needs of the software certification.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AlexGb wrote:
I just needed a constant hex-file for the needs of the software certification.

I am VERY confused.  If the contents of the .HEX can never change, then what is the problem?  Once you have a build, it doesn't matter if you start using a toolchain that can do the job in half the cycles and have the bytes of code space, as THE OUTPUT CANNOT CHANGE ANYWAY.

 

[edit]  ...which brings to mind an interesting possibility:  Some toolchains will use evaluation/optimization methods that are not necessarily deterministic as to the exact output, even though that output may be exactly equivalent. 

 

But again, more than one build cannot be done with your criterion anyway so a moot point.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Last Edited: Fri. Jun 14, 2019 - 02:34 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:

I am VERY confused.  If the contents of the .HEX can never change, then what is the problem? 

 

The contents of the hex file DO change from compilation to compilation. That is the problem. Certification procedures require that I must implement the compilation in the presence of the certification supervisor and get a hex file completely equivalent to the one I declared and fixed in advance in programme documentation. That is, the hex file created "here and now" in the presence of the supervisor should not differ from the file I provided earlier in the documentation with the fixed checksum.

 

Last Edited: Fri. Jun 14, 2019 - 04:01 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AlexGb wrote:
That is, the hex file created "here and now" in the presence of the supervisor should not differ from the file I provided earlier in the documentation with the fixed checksum.

If you already have that file, from the previo0us build, then use that one...

 

As I said, this can be a very deep question depending on your toolchain and how you are using it. 

 

Anyway, neither Cliff nor I noted that this is apparently an AVR32, so this is in the wrong forum.

 

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:

If you already have that file, from the previo0us build, then use that one...

As I said it is not the problem. Of course I can use the file I compiled once whatever it contains. It’s not rocket science. The problem is in stupid certification procedures where I must compile it once again and it must be identical. “Identical” means it can differ, for example, in debug info but not in clear code itself. It is checked by the supervisor with the special soft. And my compilation didn’t meet to this check.

Apparently, only toolchain developers can clarify the issue as it’s about complex algorithms.

Meanwhile, my local problem resolved.

Thank you.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
, so this is in the wrong forum.
Err no, this is "compilers" in the "AVR" section and that's both AVR8 and AVR32(UC3) (even if, as we all know, they aren't really AVRs)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I compared two .lss files when hex files have differences.

I saw that from time to time the compiler uses different commands. BRLO or BRCS.

(image in attach).

Attachment(s):