• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 2 answers
  • Subscribers 52 subscribers
  • Views 3282 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CCS5.2 Import Includes Pathing on Win7 & qs-bldc RDK 9017 firmware

Genatco
Guru 54087 points

Being very new to CCS & recently tested Keil on this same package 9017, within minutes was building the project without much effort. That's not the case with CCS V5.2.1 simply importing an existing Ti built Eclipse project is being very difficult. Would simply like to open the original CCS folder project but No option to open an existing project so the import wizard has to TRY and make sense of the Includes paths.

The problem after importing and deleting this same project 20 times with only 1 successful compile - compiler started to complain about Symbols not being found on successive runs so how it actually created a 49k bin file build the exact size of the packed bin is beyond my imagination to figure out.

This is what I have figured out so far ; CCS does not generate the proper include path names when the import source files path are source file folders in the CCS work spaces directory. It was necessary to remove the default includes path syntax under C/C++ General Paths & Symbols properties in order to clear the path warnings to even get this far. 

I'd like to see the tree of all project source files that came in the Ti package source imported to the solution, while importing from any other directory not being the WSD only copies over a few of the files from the discovered Ti CCS selected projects while it leaves the include source files in their home folder and creating an original project root path entry in the linked resources variables properties dialog. This was the only solution that actually would build the project one time while any repeat builds failed  stating "Error ## Symbols not found" escalating the error ## count of Symbols missing up and down every successive build or rebuild. Checked the permissions on WSD folders each show ownership all folders below root.

In this example below the project source files were homed in the WSD path prior to importing - then setting Linked resources path variable of original project root to the new target folders under the WSD.

  

 

  • 0
    TI__Guru**** 173310 points

    The recommended way of importing Stellarisware examples is the following:

    Go to menu Project->Import existing CCS Eclipse Project, and browse to the folder what contains the project (such as \Stellarisware\boards\xxxx\hello). This will make a copy of the project in your workspace directory and copy some (not all) source files to the project folder within your workspace. Note that it is just the way Stellarisware is structured and the examples are created that causes some of the source files and the include files to be "linked" to their original locations and not "copied" to your working project folder. Building the project after importing it in this manner should build without errors.

    If you really wish to have a full copy of all files (including header files) in your project folder, that would involve some work on your part, not only in copying all the related files to your workspace but also in modifying the linked resource path variables and include paths, as you have already noticed. However it is not necessary for a simple import/build of example projects to get started.

  • 0 in reply to AartiG
    Guru 54087 points

    I have also done as you suggested import from the detected projects the wizard found which BTW created all the linked resource paths the very same way as when unselected the copy files check box. The copy files box exists in order to assign local path hierarchical structure to a project while keeping unmodified sources files as is without any changes that might even exist across the network somewhere. The error message thrown during build makes no since becuse the file it complains it can not open is expanded in resource manager (Lwipopts.h). The unresolved includes violate the includes path shown below so something is not working in CCS as intended or quite possibly the Vinilla flavor is not so vinilla bean derived.

    Doing the wizard import with copy files box selected did import some of the source files as you suggest it should but concatenated parsed invalid symbol resources path names is very likely reason for the random symbols not found errors during build. The solution explorers report window shows all the imported paths as warnings either way the files are imported with or without copy. This failure makes it necessary to manually fix the source files parsed path entries in CCS which makes confusion of an existing projects structured build order. I have only a limitted idea what is needed for the entire build since Keil also used an external make library link of the source files much like CCs is doing however actually managed to build the very same project I now can't build with CCS. I uninstalled Keil before install CCS and still have VS 2005 installed.

    FWI: WIn7 Sp1 has built in security principal named (Trusted Installer) who assumes the role of Owner by default over all folders and files during Win7 setup. I did not like this trusted installer fellow not allowing me access to delete folders or files being a User in the Administrators group assigned at the Root. My name the is now Owner of all files and folders. Even so several times I was unable to delete imported folders under the WSD project tree when CCS was closed  some other security principal was the own even though it displayed my name as owner I could not delete the folder until taking ownership once again.

  • 0 in reply to Genatco
    TI__Guru**** 173310 points

    Brett,

    I'm not sure what may be happening in your case. Unless this is a really old version of Stellarisware or it is somehow corrupted, the examples should simply import and build out of the box without any errors. This has been pretty well tested and we have had many customers use it as-is and have not had any issues building them.

    Are you using the latest versions of CCSv5 and Stellarisware?
    Are you importing the example directly from the Stellarisware directory where they were installed?

    I would suggest starting with a clean version of Stellarisware to make sure no files from the original installation were inadvertantly deleted, or importing a different unmodified example. Be sure to use the menu item Project->Import Existing CCS Eclipse Project and browse to the original location of the project folder in the Stellarisware installation.

  • 0 in reply to AartiG
    Guru 54087 points

    Thanks Arti you tipped me off about the *.h files in the root project folder path  - The root SW path entry for the WSD found under properties resources linked resources was not being traversed by the compiler for the includes, strangely adding the source.h path, below shown highlighted under paths & symbols fixed the unresolved includes however as you can see once again the Symbols are an issue as they were with an import  copy files method. The path to the driverlib-Cm3 library is also added - no help.

    My mind would not allow me to believe the resources links paths  were not migrating downward.

    This path statment for the library diaspeared all on it own so I added it back in.

    Now one can see the original symbol errors generated after performing an remote project import with file copy however all project source files are now local to the WSD and not in some obscure place on another drive path or across the network.

  • 0 in reply to Genatco
    Guru 54087 points

    I give up on homing WSD project source files in CCS its just to difficult - makes absolutely no sense the way import creates numerous references paths in two completely different folder paths and has Symbol errors either way the import is done. Mysteriously the CM3 library project was built when building the Qs-bldc project without being told to do so but low and behold there be *.obj files in the debug folder. Now try to issue a rebuild command to the CM3 library project and you are told "Nothing to do." That is because the source files are not present so the cmd script is helpless.

    Now to waste even more time trying to figure out why the few Symbol errors are happening.

     

  • 0 in reply to Genatco
    TI__Guru**** 173310 points

    The specific symbol errors in the last screenshot refer to ConfigureDevice and Updater. But these functions should not even be needed/referenced for the default boot_eth example.

    Are you importing the example under \StellarisWare\boards\rdk-bldc\boot_eth? In this example, the file bl_startup_ccs.s contains the following code:

    EnterBootLoader:
     .if $$defined(ENET_ENABLE_UPDATE)
        .ref    ConfigureEnet
        bl      ConfigureEnet
     .elseif $$defined(CAN_ENABLE_UPDATE)
        .ref    ConfigureCAN
        bl      ConfigureCAN
     .elseif $$defined(USB_ENABLE_UPDATE)
        .ref    ConfigureUSB
        bl      ConfigureUSB
     .else
        .ref    ConfigureDevice
        bl      ConfigureDevice
     .endif

    Also in bl_config.h, ENET_ENABLE_UPDATE is defined while the others (CAN and USB) are not, thereby the call to ConfigureDevice should not occur.

    So I don't understand why the reference to ConfigureDevice (and similarly Updater) is required in your build unless there were modifications made to the code. This example (and others) build without errors for me.

    If you are physically copying the examples over to your workspace directory and then trying to import from there, that could result in problems and errors, as there are many references and usages of linked resource path variables and build variables, that are quite cumbersome to modify by hand. But if you import the examples directly from the Stellarisware installation folder, it should work well. I'm sorry you are having all these issues but they really are quite unusual.

  • 0 in reply to AartiG
    Guru 54087 points

    Aarti tanks for your help : )

    The 2 symbol errors went away after issuing a rebuild on the parent project since issuing a rebuild on the child reference renders a nothing to build error.

    Did you see the homed folders under the WSDir was down to 14 symbol reference errors - prior to scrapping it all. The make fies Ti compiler/Linker in CCS use SW_Root & ../../../ URi respectively. later figured the 14 symbol errors were likely broken links the Ti compiler could not resolve using make file paths syntax ../../../ since I changed all the SW_Roots to a URl format. The import wizard made many erroneous path entries for all my manually copied source project folders inside the CCS work space directory. I would say the copy files selection box is not as intuitive as I believed it to be.

    The import paths are working fine this 3rd time around for copies the wizard made. Possibly the read only security attribute on Win7 (files only in folders) is causing this behavior since this time I remove it from the WSD prior to performing import but RO attribute keeps returning to (My Documents) folder as an inherited default security model. I alwasy keep in mind 95% of all software installs and directory tree file manipulation problems are related to the NT security model being even more layers of protection under Windows7.