• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 54 subscribers
  • Views 1665 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/TMS320F28069M: Linking fails after longer pause in project development

Jonathan Lock
Intellectual 775 points
Part Number: TMS320F28069M
Other Parts Discussed in Thread: SYSBIOS, STRIKE

Tool/software: Code Composer Studio

Hi all,

Here's what's (hopefully) an issue that's easy to resolve. After a longer hiatus I've been tasked to modify some functionality in a project that hasn't been modified for about a year. I've previously run CCS and successfully built the project on my PC, after which the project was placed in a git repository (containing all directories/files, which may be a root cause of the issue? Is there some suggestion/guide as to which files to include in a git repo?) but when attempting today the linker fails and generates a long list of undefined symbols, the start of which is

--------------------------------------------------

<Linking>

 undefined                         first referenced      
  symbol                               in file           
 ---------                         ----------------      
 _ADC_disable                      ./board/board_init.obj
 _ADC_disableInt                   ./board/board_init.obj
 _ADC_disableVoltRefLoConv         ./board/board_init.obj
 _ADC_enable                       ./board/board_init.obj
<list continues>

--------------------------------------------------

I haven't (to my knowledge) made any changes to the project, other than cloning the git repository to a different location on disc. That said, I've gone through the path variables defined in the project and they're all defined in a relative sense and I know I've successfully moved the project around in the past.

The linker command contains something like

--------------------------------------------------

<path to home>/ti/c2000cgt_6_2_11/bin/cl2000" -v28 -ml -mt -O4 <snip>  "./board/F2806x_headers/source/F2806x_CpuTimers.obj" "./board/F2806x_headers/source/F2806x_GlobalVariableDefs.obj"  <snip> "../board/F2806x_headers/cmd/F2806x_Headers_nonBIOS.cmd" "../f28069_ram_lnk.cmd"  -llibc.a -lrts2800_ml.lib

--------------------------------------------------

So to my knowledge all the undefined symbols should be resolvable?

Furthermore, CCS occasoinally emits error messages along the lines of:

--------------------------------------------------

Could not write metadata for '/RemoteSystemsTempFiles'.
<path to project>/.metadata/.plugins/org.eclipse.core.resources/.projects/RemoteSystemsTempFiles/.markers.snap (No such file or directory)

--------------------------------------------------

However, I've verified that the entire directory is owned by my user so I don't know why CCS is unable to write to the directory.

I don't really know what else to do to resolve this issue other than creating a completely new project, which I'd like to avoid, as I'd have to  somehow migrate all the project settings =(

  • 0
    TI__Guru**** 171094 points
    Hi,

    From the first error snippet, it seems you are missing either a .C file named board_init.c or a library that contains the missing symbols. Perhaps this file was not pushed to the Git repo?

    Regards,
    Rafael
  • 0 in reply to desouza
    Intellectual 775 points

    Hi Rafael,

    To the best of my knowledge all relevant source files are built, the console output during a build indicates at one point

    --------------------------------------------------

    Building file: ../board/board_init.c
    Invoking: C2000 Compiler
    <snip>
    Finished building: ../board/board_init.c

    --------------------------------------------------

    and during the linking process I can see that board_init.obj is included in the link command. (And I've verified that there exists a board.obj file in the expected location).

    I'm considering simply creating a new project to resolve this issue, do you know if there's an easy way to export all "important" project settings? I.e. path, compiler, linker, post-build, (and so on) settings? Maybe some way of converting a "standard" project to a makefile project? (After which I could create a new project and simply run make to build everything?)

    Thanks for the help!

    Jonathan

  • 0 in reply to Jonathan Lock
    TI__Guru**** 171094 points
    Jonathan,

    Hmm, quite interesting. I really can't tell what is going on with your build.

    Before you migrate your project, can you try to completely delete the output directory (Debug, Release or whatever preset custom name) and retry to build? I have seen some inexplicable errors go away (especially if SYSBIOS is used) when the whole temporary build and makefiles are erased.

    I would also try to simply create a new copy of the project (Ctrl-C Ctrl-V on the Project Explorer) and see if it works.
    processors.wiki.ti.com/.../Projects_and_Build_Handbook_for_CCS

    To validate if a new project is a necessary step, then I usually create a new project and copy and paste the options shown in the "Summary of flags set", obviously along with all the necessary source files:
    e2e.ti.com/.../968986

    Keep in mind this method expands all the Build variables, thus not being ideal as a permanent solution. Unfortunately at this moment I couldn't find a way to properly duplicate only the build options without manually editing the .cproject file.

    At last; from an Eclipse standpoint, a pure makefile project does not use any of the advanced source code browsing capabilities of its IDE, thus making the least ideal of the solutions.

    I will try to find additional references and report back to this thread if I find anything.

    Regards,
    Rafael
  • 0 in reply to desouza
    Intellectual 775 points

    Rafael,

    Thanks for the ideas, unfortunately however none of the suggestions made any difference.

    That said, I compared the filesystem contents of the git repository with a previous backup (that compiles correctly), and noticed that the only difference was the presence of several empty directories in the .metadata subdirectory (which are ignored by design by git). By manually adding an empty file (e.g. '.gitkeep') in all directories in my backup and commiting the results I managed to get a working copy.

    Does this strike you as an unsafe method of resolving the problem? I'm slightly concerned that CCS will at some point determine it needs to create another empty directory, which git won't capture, causing subsequent builds from the repository to fail. Any ideas as to whether this is a fault-mode that you'd expect to occur in practice or if I only needed to create these dummy files once?

    Thanks,

    Jonathan

  • 0 in reply to Jonathan Lock
    TI__Guru**** 464751 points

    Jonathan Lock said:
    and noticed that the only difference was the presence of several empty directories in the .metadata subdirectory (which are ignored by design by git). By manually adding an empty file (e.g. '.gitkeep') in all directories in my backup and commiting the results I managed to get a working copy.

    What are the names of these directories? Is one of them "RemoteSystemsTempFiles", which you alluded to before? That folder is generated by the RSE plug-in that comes with CCS. It is actually not needed for your build and should not impact it in any way. 

  • 0 in reply to Ki
    Intellectual 775 points

    I found the following empty directories that I placed an empty file named .gitkeep in to preserve:

    (./ being the root workspace directory)

    $ find ./ -name *gitkeep
    ./dvt/AnalysisSolutionsTemp/.gitkeep
    ./.metadata/.plugins/org.eclipse.debug.core/.gitkeep
    ./.metadata/.plugins/org.eclipse.rtsc.xdctools.buildDefinitions.DSPBIOS/.gitkeep
    ./.metadata/.plugins/org.eclipse.cdt.managedbuilder.core/.gitkeep
    ./.metadata/.plugins/org.eclipse.tm.terminal.view.ui/.gitkeep
    ./.metadata/.plugins/com.ti.dvt.uia/.gitkeep
    ./.metadata/.plugins/com.ti.dvt.datamodel/DVT Solutions/.gitkeep
    ./.metadata/.plugins/org.eclipse.core.resources/.projects/RemoteSystemsTempFiles/.gitkeep
    ./.metadata/.plugins/com.ti.uia.sessionmgr.view/.gitkeep
    ./.tempFiles/.gitkeep

  • 0 in reply to Jonathan Lock
    TI__Guru**** 464751 points
    Are you checking the entire workspace folder into version control? Workspaces are not designed for that. Only contents in the project folder should be checked in. If the current process is to have the whole workspace in version control and the you checkout that workspace and point CCS to it, that will not work (well)
  • 0 in reply to Ki
    Intellectual 775 points

    Hmm, that could well be the reason for the noted behavior. Would it be correct to state that the project directory contains all relevant information? (E.g. project, compiler, and linker settings?)

  • 0 in reply to Jonathan Lock
    TI__Guru**** 464751 points
    Yes, the project metadata (the .*project files inside the project folder) have most of the relevant information in regards to build options, project settings, etc:
    software-dl.ti.com/.../sdto_ccs_source-control.html

    Thanks
    ki