Please note as of Wednesday, August 15th, 2018 this wiki has been set to read only. If you are a TI Employee and require Edit ability please contact x0211426 from the company directory.
Importing CCSv3 Projects into CCSv4
CCSv4 has a new project format based on Eclipse projects and does not support CCSv3 based *.pjt files. Such files must be migrated to support the new project format. CCSv4 provides an 'Import Legacy CCS Project Wizard' to help with the migration.
Import Legacy CCS Project Wizard
The 'Import Legacy CCS Project Wizard' is a tool to help migrate a CCSv3 project to a CCSv4 project. The user simply specifies a CCSv3 *.pjt to import and the wizard will guide the user through the migration to generate a CCSv4 project and add it to the workspace. The migration is not always perfect and there may be some manual tweaking to the generated project afterward to fix any migration issues.
Let's walkthrough a step-by-step example of using the wizard to import the NDK 2.0 network client demo CCSv3.3 project and some manual tweaking needed afterward to fix some migration issues:
Launch the wizard by selecting 'Project->Import Legacy CCSv3.3 Project'
Specify the CCSv3 *.pjt file to import: A project can be explicitly specified using the 'Browse...' button with the 'Select project' option or the the 'Select search-directory' can be use to select a folder to recursively search for CCSv3 projects to import. Any eligible projects that can be imported will appear in the 'Discovered legacy projects' list. Enabling the 'Copy projects into workspace' checkbox will copy the project and associated files into the CCSv4 workspace. In the example, the NDK network client demo project will be explicitly selected and the project files will be left in the existing location:
Specify CGT version to use: The default version of the CGT to be used with CCSv4 will be the version of the CGT that ships with CCSv4. The use can specify whether to use the default version for the migrated project or some other CGT version installed. Selecting on the project in the list and hitting the 'Edit...' button will launch another dialog to select a different CGT version. In the example, the default version is used:
Specify DSP/BIOS version to use: Similar to above, the user has the option to choose whether to use the default version or some other installed version of DSP/BIOS. It is recommended that all DSP/BIOS 5.x users choose the default 5.4 version that comes with CCSv4. This version is compatible with previous 5.x versions and only version 5.4 will work with the RTA and ROV tools in CCSv4. In the example, the default version is again used:
A common root can be defined to help with the portability of projects. This step is optional.
Hitting 'Finish' will complete the import and the newly generated CCSv4 project will appear in the CCSv4 workspace. Any migration issues encountered will be logged in a file called 'migration.log' in the project location.
It is recommended to open this log to check for any issues. For the example, we can see that there is a duplicate definition of the same linker command file (once by the 'client.cmd' file and once by CCS):
!WARNING: File 'client.cmd' explicitly references a TConf-generated linker-command file (line 9). Please remove this reference when migration completes - CCS now automatically handles generated files during project-build.
Commenting out the line 9 in 'client.cmd' will resolve this issue.
Next is to see if the new project will build. When attempting to build the project, an error occured:
By checking the build console, it appears that the include path to CSL is being defined twice (see above screenshot). The first is "C:/CCSTUD~1.3/C6000/csl/include" and the second is "C:/CSL/csl_c6488/inc". The latter path is the one for this project so it must be picking up the former path instead and hence causing an error. The former path needs to be removed from the build options:
After removing the first CSL include path:
Rebuilding again now shows that the project has been successfully built:
Running from the Command Line
Legacy projects can also be imported using a command line utility. This is useful for automating the import of many legacy projects. More details are covered in this wiki topic.
Known Migration Issues
Missing Source Files
For users of the CCSv4 Microcontroller product, any imported CCSv3 projects with DSP/BIOS dependencies may be missing linked source files (source files outside the directory of the *.pjt file). This is because the Microcontroller version does not come with DSP/BIOS and CCSv4 is unable to resolve this dependency. Note that even if your application is not a DSP/BIOS application, there may still be some references to DSP/BIOS in the *.pjt file. There are two workarounds:
- Option 1 - Remove the reference to DSP/BIOS in the *.pjt file and re-import to project: This can be done if the project is not a DSP/BIOS application and you can safely remove any dependencies to DSP/BIOS. Simply open the *.pjt file in a text editor and remove the line: Tool="DspBiosBuilder"
; Code Composer Project File, Version 2.0 (do not modify or remove this line) [Project Settings] ProjectName="DSP280x" ProjectDir="C:\tidcs\c28\DSP280x\v150\DSP280x_examples\ecap_apwm\" ProjectType=Executable CPUFamily=TMS320C28XX Tool="Compiler" Tool="DspBiosBuilder" Tool="Linker" Config="Debug" Config="Release"
NOTE: Before the project can be re-imported, the generated metadata files during the last project import will need to be deleted otherwise an error dialog will appear during the process. The metadata files are found in the same location as the *.pjt being imported. They are files/folder that start with a period ('.settings', .ccsproject', etc).
- Option 2 - Install standalone DSP/BIOS and RTSC: DSP/BIOS and RTSC are available for download here.
Object File Directory
The following build error(s) may occur with some imported projects:
C:\Program Files\Texas Instruments\ccsv4\utils\gmake\gmake -k all C:\Program Files\Texas Instruments\ccsv4\utils\gmake\gmake: *** No rule to make target `myFile.obj', needed by `myApp.out'. ...
In those cases, check the project build properties and see if the object file directory has a path to a subfolder of the same name as the active configuration (i.e. 'Debug'). Changing this path to any other location will resolve the issue. Having it blank will place the *.obj files in a subfolder with the name of the active configuration within the project folder.
CSL and XDAIS
CCSv4 does not ship with CSL or XDAIS. If a CCSv3 project that used either (or both) was migrated to a CCSv4 project, the include search paths and library search paths will need to be updated in the build properties to existing locations of the CSL and XDAIS files.
Any initial and final build steps in the CCSv3 project will be added to *.bat files (one for all initial build steps and one for all final build steps) during the project migration. Those *.bat files are then called as CCSv4 build steps.