TMS320F28379D: How to change CCS to use a different version of C2000 ware>

Under the CCS Project Properties General -> Products have you tried the Edit option to change the version of C2000Ware used?

On the PC used for the above there is only one C2000Ware version installed, so haven't tested changing the version.

Yes I have done that but the "includes" project does not change. It appears that the path to C2000ware is contained in s system variable.

So to figure this out I have done the following;

I imported an example project "blinky_dc_cpu01 - CPU1_RAM_DEBUG" - No problem. I see that it was set up to use C2000WARE ver 2.00.00.02. So I changed the product to 3.4.0.00. I would have thought that would be enough to point everything to that product. But once again the "includes" project folder is still pointing to 2.00.00.02.

I am unable to change anything related to getting CCS to use a different version of C2000 Ware.

The issue seems to related to a system variable called    "INSTALLROOT_F2837XD"  The contents of this variable seems to contain another system variable  "ORIGINAL_PROJET_ROOT.........."   --- see the screen shot below.

Now then that variable contains the path to the project blinky.

Now the problem is I cannot edit the content of this variable or any variable for that matter. I can only "extend" it and I have no idea what that means.

I must be missing something because nobody should have to dig such a deep hole to make a simple change like this.

I find this very frustrating. Is there some documentation I can read on how yo go about getting the development environment set up the way I want it? I have now created fresh empty project and added the 3.04 C2000 ware and there are no references to that product in the "includes project folder. I am totally confused by all this.

Thanks.   Dave.....

David Petryk said:

I see that it was set up to use C2000WARE ver 2.00.00.02. So I changed the product to 3.4.0.00. I would have thought that would be enough to point everything to that product.

Now have multiple C2000Ware versions installed to investigate, on examples for a TMS320F28377D.

Start by importing led_ex1_blinky from C2000Ware 3.01.00.00, which has C2000Ware_3_01_00_00_Software in the compiler include and linker library paths:

Building file: "../device/device.c"
Invoking: C2000 Compiler
"C:/ti/ccs1040/ccs/tools/compiler/ti-cgt-c2000_20.2.5.LTS/bin/cl2000" -v28 -ml -mt --cla_support=cla1 --float_support=fpu32 --tmu_support=tmu0 --vcu_support=vcu2 -Ooff --include_path="C:/Users/mr_halfword/workspace_v10/led_ex1_blinky" --include_path="C:/Users/mr_halfword/workspace_v10/led_ex1_blinky/device" --include_path="C:/ti/C2000Ware_3_01_00_00_Software/driverlib/f2837xd/driverlib" --include_path="C:/ti/ccs1040/ccs/tools/compiler/ti-cgt-c2000_20.2.5.LTS/include" --define=CPU1 --diag_suppress=10063 --diag_warning=225 --diag_wrap=off --display_error_number --abi=eabi --preproc_with_compile --preproc_dependency="device/device.d_raw" --obj_directory="device"  "../device/device.c"
Finished building: "../device/device.c"
 
Building target: "led_ex1_blinky.out"
Invoking: C2000 Linker
"C:/ti/ccs1040/ccs/tools/compiler/ti-cgt-c2000_20.2.5.LTS/bin/cl2000" -v28 -ml -mt --cla_support=cla1 --float_support=fpu32 --tmu_support=tmu0 --vcu_support=vcu2 -Ooff --define=CPU1 --diag_suppress=10063 --diag_warning=225 --diag_wrap=off --display_error_number --abi=eabi -z -m"led_ex1_blinky.map" --stack_size=0x100 --warn_sections -i"C:/ti/ccs1040/ccs/tools/compiler/ti-cgt-c2000_20.2.5.LTS/lib" -i"C:/ti/ccs1040/ccs/tools/compiler/ti-cgt-c2000_20.2.5.LTS/include" --reread_libs --diag_wrap=off --display_error_number --xml_link_info="led_ex1_blinky_linkInfo.xml" --entry_point=code_start --rom_model -o "led_ex1_blinky.out" "./led_ex1_blinky.obj" "./device/F2837xD_CodeStartBranch.obj" "./device/device.obj" "../2837xD_RAM_lnk_cpu1.cmd" "C:/ti/C2000Ware_3_01_00_00_Software/driverlib/f2837xd/driverlib/ccs/Debug/driverlib.lib"  -llibc.a 
<Linking>
Finished building target: "led_ex1_blinky.out"

With the above example, in the CCS Project Properties under General -> Products simply changed the C2000Ware version from 3.1.0.00 to 3.4.0.00. A rebuild showed the compiler and linker paths had changed to C2000Ware_3_04_00_00_Software:

Building file: "../device/device.c"
Invoking: C2000 Compiler
"C:/ti/ccs1040/ccs/tools/compiler/ti-cgt-c2000_20.2.5.LTS/bin/cl2000" -v28 -ml -mt --cla_support=cla1 --float_support=fpu32 --tmu_support=tmu0 --vcu_support=vcu2 -Ooff --include_path="C:/Users/mr_halfword/workspace_v10/led_ex1_blinky" --include_path="C:/Users/mr_halfword/workspace_v10/led_ex1_blinky/device" --include_path="C:/ti/C2000Ware_3_04_00_00_Software/driverlib/f2837xd/driverlib" --include_path="C:/ti/ccs1040/ccs/tools/compiler/ti-cgt-c2000_20.2.5.LTS/include" --define=CPU1 --diag_suppress=10063 --diag_warning=225 --diag_wrap=off --display_error_number --abi=eabi --preproc_with_compile --preproc_dependency="device/device.d_raw" --obj_directory="device"  "../device/device.c"
Finished building: "../device/device.c"
 
Building target: "led_ex1_blinky.out"
Invoking: C2000 Linker
"C:/ti/ccs1040/ccs/tools/compiler/ti-cgt-c2000_20.2.5.LTS/bin/cl2000" -v28 -ml -mt --cla_support=cla1 --float_support=fpu32 --tmu_support=tmu0 --vcu_support=vcu2 -Ooff --define=CPU1 --diag_suppress=10063 --diag_warning=225 --diag_wrap=off --display_error_number --abi=eabi -z -m"led_ex1_blinky.map" --stack_size=0x100 --warn_sections -i"C:/ti/ccs1040/ccs/tools/compiler/ti-cgt-c2000_20.2.5.LTS/lib" -i"C:/ti/ccs1040/ccs/tools/compiler/ti-cgt-c2000_20.2.5.LTS/include" --reread_libs --diag_wrap=off --display_error_number --xml_link_info="led_ex1_blinky_linkInfo.xml" --entry_point=code_start --rom_model -o "led_ex1_blinky.out" "./led_ex1_blinky.obj" "./device/F2837xD_CodeStartBranch.obj" "./device/device.obj" "../2837xD_RAM_lnk_cpu1.cmd" "C:/ti/C2000Ware_3_04_00_00_Software/driverlib/f2837xd/driverlib/ccs/Debug/driverlib.lib"  -llibc.a 
<Linking>
Finished building target: "led_ex1_blinky.out"

As for the issue with changing the version from a project imported from v1 or v2 will check to see how the project was setup.

OOps I clicked the wrong thing and indicated this solved my issue. - IT IS NOT.

Your description of just changing the product was what I tried first. I'm surprised it works for you.

I have am using Version: 10.4.0.00006 of CCS. IS it a CCS problem or is it a project problem?

I cannot answer your question "ORIGINAL_PROJECT_ROOT.........." variable and what is it set to?" because I have deleted the project and going to try again from scratch again.

Is it possible to set a include path lets say something like "C:\ti\C2000Ware\C2000Ware_3_04_00_00\device_support\f2837xd\common" and will the compiler and linker search through all the sub folders for what its looking for? Or do you have to have an explicit path for everything?

What are all these system variables used for? Is there any documentation or standards for them? Are they just leftovers from somebody's good idea?

What else can I try?

David Petryk said:

As you can see I tried to direct everything to 3.04 but CCS did not respond as expected.

The screen shows shows what appears to be a hard-coded path to C:\ti\C2000Ware_1_00_04_software\driverlib\f2837xd\driverlib in the project. That might been hard-coded when the project was originally created.

You should be able to select the path C:\ti\C2000Ware_1_00_04_software\driverlib\f2837xd\driverlib and delete it from the search path.

David Petryk said:

IS it a CCS problem or is it a project problem?

I suspect that is a project problem, as each project can have it's paths set up differently.

David Petryk said:

What are all these system variables used for? Is there any documentation or standards for them?

Good question - I haven't been able to find a description of what the different CCS products set the variables to.

From trying to investigate what the products version controls:

a. The COM_TI_C2000WARE_SOFTWARE_PACKAGE_INSTALL_DIR path variable depends upon the C2000Ware product version set under General -> Projects

b. The COM_TI_C2000WARE_SOFTWARE_PACKAGE_INSTALL_DIR path variable isn't present in the <variableList> within the .project file.

c. The .cproject file records the C2000Ware version with a line such as the following:

<listOptionValue builtIn="false" value="PRODUCTS=c2000ware_software_package:3.4.0.00;"/>

I.e. CCS 10.4 appears to be automatically populating the COM_TI_C2000WARE_SOFTWARE_PACKAGE_INSTALL_DIR path variable according to the C2000Ware version selected.

David Petryk said:

What else can I try?

The paths to C2000Ware in the compiler and linker paths needs to be set from variables which are derived from COM_TI_C2000WARE_SOFTWARE_PACKAGE_INSTALL_DIR in some way.

Are you able to post your complete project, or failing that the .ccsproject, .cproject and .project files?

It will be easier to give more definitive advice if can look at all the project settings.

I did a lot of investigating looking for the root cause; I would like you to try this;

David ,

If the project has a hard coded path to version 1_00_04 of C2000Ware, then you will have to manually update it to use a different version.  Changing the products in CCS won't help.

Best Regards

Siddharth

Well the thing is that they are not hard coded. They use a system variable that is using yet another system variable which is not being updated properly.

David, 

Pls try to compile after updating the system variable by double clicking on it as shown below. 

Best Regards

Siddharth

Siddharth, apparently you are not reading all of this thread. I the process of trying to figure out why this is not working I have done at least 75 compiles changing all sorts of stuff including what you are asking me to do. In fact that was the first thing I tried.

Here is what I found;

If you import a project from whatever version of C2000ware without changing the original source you copy the project to your workspace and check the little box "copy projects into workspace" yes it copies the source but the project is still referencing stuff from the place it was copied from. So in my case I did not want to modify the original project that was contained in the C2000ware installation and as such I ticked the little box "copy projects into workspace" thinking I would be working in my workspace not in the original location. Well that is partially true. If you don't check the box then everything works as expected because you are working out of the C2000WARE Ver xxxx. folder. However if you do check the box "copy projects into workspace" then things don't work as expected because, as I have discovered you are changing some of the project stuff in the original location and not in your local copied project.

I find that having that little box "copy projects into workspace" in the import function is very misleading. It implies that you can copy a project from a sacred source into your local project folder (which it does) but when you compile it actually is compiling the project in the original source location. It all looks and feels like you are operating totally out of your local copy but you are not. That's why changing products does not change anything in the "includes" project folder because its referencing the original location.

There should be a big warning sign stating the "copy projects into workspace makes a local copy but the original project may be modified" or something to that effect. The result of the project build resides in the original location and not in your local project folder.

David Petryk said:

Now change the product to a different revision and see if the includes get changed properly.

That should work as expected.

Yes, that worked.

David Petryk said:

Now do it again except when importing check the box that says "copy projects into workspace".

Now change the product to some other revision and see if the includes get changed properly.

I predict that the includes will not get changed.

The includes did not get changed.

The difference between the two appears to be how the ORIGINAL_PROJECT_ROOT path variable gets populated after the project is imported:

1. When the include paths change when the C2000Ware version in changed, then ORIGINAL_PROJECT_ROOT is derived from the COM_TI_C2000WARE_SOFTWARE_PACKAGE_INSTALL_DIR path variable, e.g.

2. Whereas when the include paths don't change when the C2000Ware version is changed, then ORIGINAL_PROJECT_ROOT is set to a fixed path base upon which C2000Ware version imported from. E.g.:

Editing the ORIGINAL_PROJECT_ROOT path variable to use ${COM_TI_C2000WARE_SOFTWARE_PACKAGE_INSTALL_DIR} instead of the hard coded path then allows the include paths to be selected according to the C2000Ware version selected under CCS General -> Products