• Locked Locked
  • Replies 3 replies
  • Subscribers 54 subscribers
  • Views 1093 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 6.0.1.004 breaks project when compiler changed and reverted

ash gokhale
Prodigy 60 points
Other Parts Discussed in Thread: CC430F6137

Summary: While auditioning an A/B test between the compiler settings; I found that the project would become unbuildable after reverting back to the original compiler. How do I repair the project?

Target device ( fet/target hardware  not necessary to reproduce ) : cc430f6137

To reproduce every time: 

1) Build a new project targeting cc430f6137 with the blink led template; this will build normally - and even produce a running eval board. 

2) Change compilers from Project Properties->General['Advanced Settings']tab->Compiler Version drop down from 'TI v4.3.5' to 'GNU  v4.9.1'

3) rebuild project.

4) Return original compiler from Project Properties->General['Advanced Settings']tab->Compiler Version from GNU  v4.9. to 'TI v4.3.5' 

5) rebuild project  - only to find that the linker fails with the following:

**** Build of configuration Debug__GNU__TI for project to_repro0 ****
 
"D:\\ti\\ccsv6\\utils\\bin\\gmake" -k all 
'Building target: to_repro0.out'
'Invoking: MSP430 Linker'
"D:/ti/ccsv6/tools/compiler/msp430_4.3.5/bin/cl430" -vmspx --abi=eabi --advice:power=all -g --define=__CC430F6137__ --diag_warning=225 --display_error_number --diag_wrap=off --silicon_errata=CPU18 --silicon_errata=CPU21 --silicon_errata=CPU22 --silicon_errata=CPU23 --silicon_errata=CPU40 --printf_support=minimal -z -m"to_repro0.map" --heap_size=80 --stack_size=80 --use_hw_mpy=F5 --cinit_hold_wdt=on -i"D:/ti/ccsv6/ccs_base/msp430/include" -i"D:/ti/ccsv6/tools/compiler/msp430_4.3.5/lib" -i"D:/ti/ccsv6/tools/compiler/msp430_4.3.5/include" -i"D:/ti/ccsv6/ccs_base/msp430/lib/5xx_6xx_FRxx" --reread_libs --warn_sections --display_error_number --diag_wrap=off --xml_link_info="to_repro0_linkInfo.xml" --rom_model -o "to_repro0.out"  "./blink.obj" -l"libc.a" -l"libmath.a" 
<Linking>
remark #10371-D: (ULP 1.1) Detected no uses of low power mode state changes using LPMx or _bis_SR_register() or __low_power_mode_x() in this project.
warning #10247-D: creating output section ".stack" without a SECTIONS specification
remark #10372-D: (ULP 4.1) Detected uninitialized Port A in this project. Recommend initializing all unused ports to eliminate wasted current consumption on unused pins.
 
 undefined first referenced
  symbol       in file     
 --------- ----------------
remark #10372-D: (ULP 4.1) Detected uninitialized Port B in this project. Recommend initializing all unused ports to eliminate wasted current consumption on unused pins.
 PADIR_L   ./blink.obj     
remark #10372-D: (ULP 4.1) Detected uninitialized Port C in this project. Recommend initializing all unused ports to eliminate wasted current consumption on unused pins.
 PAOUT_L   ./blink.obj     
 
 WDTCTL    ./blink.obj     
>> Compilation failure
 
error #10234-D: unresolved symbols remain
error #10010: errors encountered during linking; "to_repro0.out" not built
gmake: *** [to_repro0.out] Error 1
gmake: Target `all' not remade because of errors.

**** Build Finished ****
  • Guru 227245 points

    Probably, switching compilers messes with the device-specific linker scripts. On CCS, the TI compiler defines hardware registers inside the linker script, while previous versions contained the addresses in the header files. This old method was faster, as the compiler could uses the addresses directly instead of creating open references, but it made it next to impossible to provide generic libraries.
    Somehow, switching back to the TI compiler breaks consistency of these things. Maybe the project folder contains an old linker script (without these definitions) and by switching to the TI compiler, this is detected and automatically used, instead of the one that came with the compiler.

  • in reply to Jens-Michael Gross
    Prodigy 60 points

    If I clean the linker trash in the project will CCS fix it at the next build time? Is there a way to repair an existing project?  What happens if the incorrect linker scripts get checked into a revision control system and someone else is using the other compiler?

  • in reply to ash gokhale
    TI__Guru**** 251490 points

    This is not, strictly speaking, a problem with the compiler tools.  But I will shed what light I can.

    CCS makes some error when changing from the GCC compiler to the TI compiler.  It fails to include the linker command file lnk_cc430f6137.cmd in the project.  You can fix this yourself by copying that file out of the directory named C:\ti\ccsv6\ccs_base\msp430\include (change the C:\ti part if needed) into the project directory.  Then manually add it to the project.  

    As for getting this corrected in the future ... I'm not sure where to file the issue.  The people I would ask have already left for the Thanksgiving holiday.  I'll have to get back to you on that.

    Thanks and regards,

    -George