• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 55 subscribers
  • Views 897 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/TMS570LS3137: .ecc section keeps moving in the map files - yet hex files stay the same

Randy Kwong
Prodigy 20 points
Part Number: TMS570LS3137


Tool/software: Code Composer Studio

We're on Windows 10 64-bit, and had just upgraded to CCS 6.0.1.00040 (to align with a neighboring dev group's configuration). We were previously using 5.5 CCS on Windows 7 64-bit.

One thing we noticed was that the map file changes with each build process despite not changing the source file, yet the compiled hex file remains the same.

Other than the generation date, the .ecc section appears to be changing on every build. I've pasted the ecc sections for 4 consecutive build processes below.

Since we're developing safety-critical applications, having auto-generated files dictating different ecc sections on every build despite not changing the source file is problematic.

We've unchecked the "Auto ECC Generation" box in the project settings. From a search in the forums, is there an outstanding CCS bug related to this?

 

Build #1

.ecc1 0 f0400000 00000004
f0400000 00000004 (.ecc1)

.ecc3 0 f0400004 00009ff4
f0400004 00009ff4 (.ecc3)

.ecc2 0 f0409ff8 00000008
f0409ff8 00000008 (.ecc2)

.ecc0 0 f040a000 00056000
f040a000 00056000 (.ecc0)

Build #2

.ecc0 0 f0400000 00000004
f0400000 00000004 (.ecc0)

.ecc2 0 f0400004 00009ff4
f0400004 00009ff4 (.ecc2)

.ecc3 0 f0409ff8 00000008
f0409ff8 00000008 (.ecc3)

.ecc1 0 f040a000 00056000
f040a000 00056000 (.ecc1)


Build #3

.ecc3 0 f0400000 00000004
f0400000 00000004 (.ecc3)

.ecc1 0 f0400004 00009ff4
f0400004 00009ff4 (.ecc1)

.ecc2 0 f0409ff8 00000008
f0409ff8 00000008 (.ecc2)

.ecc0 0 f040a000 00056000
f040a000 00056000 (.ecc0)

 

Build #4

.ecc2 0 f0400000 00000004
f0400000 00000004 (.ecc2)

.ecc0 0 f0400004 00009ff4
f0400004 00009ff4 (.ecc0)

.ecc1 0 f0409ff8 00000008
f0409ff8 00000008 (.ecc1)

.ecc3 0 f040a000 00056000
f040a000 00056000 (.ecc3)

 

 

 

  • 0
    Prodigy 20 points
    I should also mention that this issue is not observed on the same CCS version (6.0.1.00040) on Win 7 64-bit.
  • 0 in reply to Randy Kwong
    TI__Guru**** 251290 points

    Those ECC sections are automatically generated.  They have the same length and contents from build to build.  All that changes is the section name, i.e. the .ecc1, .ecc2, and so on.  They move around.  The hex output is not affected by a minor difference like that.  So long as the sections are in the same address order, and have the same contents, the hex output will be the same.  

    I agree this needless difference is annoying.  So, I filed CODEGEN-4251 in the SDOWP system to have this addressed.  You are welcome to follow it with the SDOWP link below in my signature.

    Thanks and regards,

    -George

  • 0
    TI__Guru* 84285 points
    This happens in 16.9.X.LTS because the ECC initialization code iterates over an unsorted list. This list's order happens to be non-deterministic. The ECC code was refactored significantly before the 17.3 branch, and now uses a set, which is always ordered. Thus, the problem will not occur in 17.3.0.STS or any release thereafter. We do not plan to address this for the 16.9.X.LTS branch. As of right now, the next LTS release with the fix will be 18.1.0.LTS.