• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 82 subscribers
  • Views 506 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.

Original question:

Importing CCS projects from another Windows computer

TMS320F280036-Q1: Why is there a difference in CCS compilation results between Unix and Windows environments?

owens shi
Intellectual 290 points

Other Parts Discussed in Thread: C2000WARE

Tool/software:

Problem Description:

Why is there a difference in the contents of the .map files generated from the same CCS V12.6 when compiled in Linux versus Windows environments?

The differences are mainly in the length and order of the const segment. See the figure below.

The left side is map under linux, the right side is map under windows

Background Information:

For ease of debugging, our project is developed and debugged using CCS V12.6 in a Windows environment. The corresponding .c & .h files and project files (.ccsproject, .cproject, .project) are uploaded to the server's Git repository. The software testing department uniformly compiles and links these files using CCS V12.6 installed on a Linux server, then releases the .out and .hex files.

  • 0
    Intellectual 290 points

    compare map.zipin this zip,one is map file compiled by windows,another is compiled by linux 

  • 0 in reply to owens shi
    TI__Guru**** 253010 points

    I suggest you focus on one question:  Why is the .const:.string section from ecapdriver.obj a different size?  Linux 0x99, Windows 0x89.  Start by comparing the preprocessor listing file.  To learn what a preprocessor listing file is, please search the C28x compiler manual for the sub-chapter titled Generating a Raw Listing File.  Use the CCS file specific options feature to enable --gen_preprocessor_listing only for ecapdriver.c.  Then build on both Linux and Windows.  Compare the two .rl files.  I'm confident you will find a difference.  Explaining that difference is likely to lead you to the root cause.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Intellectual 290 points

    Thanks for the prompt reply.

    I compared the rl files compiled under the two environments, and the differences mainly come from the input parameter of __error__ (the path where the file is located), as follows

    example : do { if(!(HRCAP_isBaseValid(base))) { __error__("C:/ti/c2000/C2000Ware_5_01_00_00/driverlib/f28003x/driverlib/hrcap.h", 154); } } while((_Bool)0);

    My understanding is that when Assert has an exception, it will call the error function, which needs the filename (including the path) and the number of lines as input parameters.
    There is a difference in the driverlib address directory between the two environments.
    Is this difference risky?

  • 0 in reply to owens shi
    TI__Guru**** 253010 points

    That ASSERT macro is similar to the macro assert from the compiler supplied standard header file <assert.h>.  But it is not the same.  Which means you can change it.  Right now, it uses the compiler predefined preprocessor symbol __FILE__.   I suggest you replace __FILE__ with something similar.  But because you control it, you can make it work the same across Windows and Linux.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Intellectual 290 points

    Thanks for the prompt reply.

    I removed the DEBUG macro from the IDE configuration so that the program would no longer call the associated ASSERT macro. Then comparing the differences.

    the main body of the map file is already the same (which inspires me),

    but the generated .hex file for OTA (generated by the IDE's C2000 Hex Utility) has a difference of 3 bytes (distributed in two different areas).

    is this risky?

  • +1 in reply to owens shi
    TI__Guru**** 253010 points

    I don't know if the difference is risky.  But I have a suggestion for how to find the cause of the difference.

    For both builds, disassemble the final executable file with a command similar to ...

    % dis2000 --all executable_file.out > disassembly_file.txt

    The disassembler dis2000 is located in the same \bin directory as the compiler cl2000.  Compare the disassembly from each build.  Inspect the labels before the address of the difference.  That shows you the name of the function (if it is code) or data variable (if it is data) associated with that address.  Search the source code to find the C file which contains that function or variable.  Then, repeat the preprocessor listing file comparison for that C file.  

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Intellectual 290 points

    The cause has been located, thank you for your support!