• State TI Thinks Resolved
  • Locked Locked
  • Replies 1 reply
  • Answers 1 answer
  • Subscribers 82 subscribers
  • Views 420 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CCS/TMS320F28377D: Linker generated CRC tables are different between builds on different machines

Susan Beiter78
Intellectual 660 points
Part Number: TMS320F28377D

Tool/software: Code Composer Studio

I used the TI application notes in SPRU513P Section 8.9 and Appendix C to generate my CRC tables and am successful in performing run-time checks as part of my executable.

I know it can be the bane of a programmer's existence to try to match CRCs across machines and tool installations, so I will preface by saying I don't *have* to match them, but I want to make sure that I understand why they don't match.  I have my two map files, and I have compared them to find what differences exist:

1. Linker version TMS320C2000 Linker PC v16.9.3   versus v16.9.6

2. The map file using the 16.9.6 linker has two additional memory regions defined (though not part of CRC tables):
DCSM_Z1_OTP 00078000 00000020 00000000 00000020 RWIX
DCSM_Z2_OTP 00078200 00000020 00000000 00000020 RWIX

3. C:/ti/ccsv7/tools/compiler/ti-cgt-c2000_16.9.3.LTS/lib/rts2800_fpu32.lib versus C:/ti/ccsv7/tools/compiler/ti-cgt-c2000_16.9.6.LTS/lib/rts2800_fpu32.lib

4. The CRC tables differ for 2 out of 4 CRCs.  .text.1 and .econst match, but .text.2 and .ramfunc do not.  Start address and size are identical, but values are different:

.text.2: algorithm=CRC32_PRIME(ID=0), page=0, load addr=00084000, size=00000e6f, CRC=219af52f
.TI.ramfunc: algorithm=CRC32_PRIME(ID=0), page=0, load addr=00086000, size=00003883, CRC=8e77c396

.text.2: algorithm=CRC32_PRIME(ID=0), page=0, load addr=00084000, size=00000e6f, CRC=1c7982e8
.TI.ramfunc: algorithm=CRC32_PRIME(ID=0), page=0, load addr=00086000, size=00003883, CRC=f94609c4

5. 4 out of 503 symbols are located at different addresses.  All four are global variables declared in the same source file.  This really puzzles me, and I am wondering, if the linker version and fpu lib are not the suspected cause of different checksums, could this be the problem?  And if so, is there a way to control how the tools order the symbols?

Thank you for your time,

Susan

  • 0
    TI__Guru**** 173310 points

    Susan,

    If the compiler tools version is different between the two builds, then there is no guarantee that the binary output or CRC will be exact. If the version of tools and options are the same, then I would expect them to be the same. 

    Susan Beiter78 said:
    2. The map file using the 16.9.6 linker has two additional memory regions defined (though not part of CRC tables):
    DCSM_Z1_OTP 00078000 00000020 00000000 00000020 RWIX
    DCSM_Z2_OTP 00078200 00000020 00000000 00000020 RWIX

    Perhaps the linker command files are different between the two builds?

    I wanted to mention another tool that you can use in future to compare object files, in case you weren't aware of it already. This tool ignores metadata like time stamps, debug information etc (which can be legitimately different between otherwise identical builds) that is not loaded to the target system, and only compares the raw data that is loaded. It is the objdiff utility in the cg_xml package.  

    Susan Beiter78 said:
    And if so, is there a way to control how the tools order the symbols?

    If the same linker command file is used for both builds and the linker settings and order in which files are passed to the linker are the same, then I would expect the symbols to be ordered the same way. There is a discussion in this page that could help with a general understanding of how things are ordered by the linker.

    Hope this helps.