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.
Tool/software: TI C/C++ Compiler
Hi guys,
Currently running CCS (v8) using C2000Ware version 1.00.05.00.
Just noticed an update to C2000Ware version 1.00.06.00 is currently
available. Downloaded and installed at c:\ti folder but not through
CCS/help-->check for updates...
I'd like to integrate it to CCS and have the newer version of
C2000Ware 1.00.06.00 to be used instead of the old. So far have not
been successful to do that. Would appreciate any help on this
integration of new versions into CCS.
Thanks,
Saleh
Saleh,
There is a list of software products and versions that CCS is aware of on your machine. That is the list in the Products section in the Preferences dialog.
Then each project will store which specific products and versions it wants to use. The project doesn't store locations. At build time CCS will populate the locations based on the products that it is aware of. This is so that different team members can have them in different locations.
So if you have a project that you imported before it will be set to use the version it was imported from. It won't automatically switch to use the newer one. You will have to go into the properties of the project and change it to use the new one.
For example here I have a project that I imported from 1.0.5. I can change it to use 1.0.6
Regards,
John
I imported the same project that is not building
MINE:
Building target: "adc_epwm_cpu01.out"
Invoking: C2000 Linker
"/Applications/ti/ccs820/ccsv8/tools/compiler/ti-cgt-c2000_18.1.3.LTS/bin/cl2000" -v28 -ml -mt --vcu_support=vcu2 --tmu_support=tmu0 --cla_support=cla1 --float_support=fpu32 -g --define=CPU1 --display_error_number --diag_warning=225 -z -m"adc_epwm_cpu01.map" --heap_size=0x400 --stack_size=0x400 --warn_sections -i"/Applications/ti/ccs820/ccsv8/tools/compiler/ti-cgt-c2000_18.1.3.LTS/lib" -i"/Applications/ti/ccs820/ccsv8/tools/compiler/ti-cgt-c2000_18.1.3.LTS/include" -i"/Users/a0792138/ti/C2000Ware_1_00_05_00_Software/device_support/f2837xd/common/cmd" -i"/Users/a0792138/ti/C2000Ware_1_00_05_00_Software/device_support/f2837xd/headers/cmd" --reread_libs --display_error_number --xml_link_info="adc_epwm_cpu01_linkInfo.xml" --rom_model -o "adc_epwm_cpu01.out" "./F2837xD_CodeStartBranch.obj" "./F2837xD_DefaultISR.obj" "./F2837xD_EPwm.obj" "./F2837xD_GlobalVariableDefs.obj" "./F2837xD_Gpio.obj" "./F2837xD_Ipc.obj" "./F2837xD_PieCtrl.obj" "./F2837xD_PieVect.obj" "./F2837xD_SysCtrl.obj" "./F2837xD_usDelay.obj" "./adc_epwm_cpu01.obj" -lrts2800_fpu32.lib -l2837xD_RAM_lnk_cpu1.cmd -lF2837xD_Headers_nonBIOS_cpu1.cmd -llibc.a
<Linking>
Finished building target: "adc_epwm_cpu01.out"
YOURS:
Building target: "adc_epwm_cpu01.out"
Invoking: C2000 Linker
"C:/ti/ccsv8/tools/compiler/ti-cgt-c2000_16.9.8.LTS/bin/cl2000" -v28 -ml -mt --advice:performance=all --define=CPU1 -g --diag_warning=225 --display_error_number -z -m"adc_epwm_cpu01.map" --heap_size=0x400 --stack_size=0x400 --warn_sections -i"C:/ti/ccsv8/tools/compiler/ti-cgt-c2000_16.9.8.LTS/lib" -i"C:/ti/ccsv8/tools/compiler/ti-cgt-c2000_16.9.8.LTS/include" -i"C:/ti/C2000Ware_1_00_05_00_Software/device_support/f2837xd/common/cmd" -i"C:/ti/C2000Ware_1_00_05_00_Software/device_support/f2837xd/headers/cmd" --reread_libs --display_error_number --xml_link_info="adc_epwm_cpu01_linkInfo.xml" --rom_model -o "adc_epwm_cpu01.out" "./F2837xD_CodeStartBranch.obj" "./F2837xD_DefaultISR.obj" "./F2837xD_EPwm.obj" "./F2837xD_GlobalVariableDefs.obj" "./F2837xD_Gpio.obj" "./F2837xD_Ipc.obj" "./F2837xD_PieCtrl.obj" "./F2837xD_PieVect.obj" "./F2837xD_SysCtrl.obj" "./F2837xD_usDelay.obj" "./adc_epwm_cpu01.obj" -lrts2800_fpu32.lib -l2837xD_RAM_lnk_cpu1.cmd -lF2837xD_Headers_nonBIOS_cpu1.cmd
Our builds are using different compilers but I don't think that is the problem. I see some different build options being used that I believe are causing the issue. For my build I can see fpu32 being set for the floating point support. This is not set for yours. Can you try setting that option here:
For me that option was set when I imported the project. Given that we end up linking the fpu32 version of the runtime support library (rts2800_fpu32.lib) I believe this option has to be set or we will get the errors you see. If I change that option in my project then I can reproduce the same errors.
Regards,
John
Saleh,
In my linker options for the adc_epwm_cpu01 project I could see fpu32 being passed but not in yours. That will lead to a mismatch the object files being generated and the rts2800_fpu32.lib
"C:/ti/ccsv8/tools/compiler/ti-cgt-c2000_16.9.8.LTS/lib/rts2800_fpu32.lib<bo
ot28.obj>" specifies ISA revision "C28FPU32", which is not compatible with
ISA revision "C2800" specified in a previous file or on the command line
error #16008-D: file
As far as the linker command file I mine is also the RAM one. Here are the linker command files that my project is pulling in:
The example really should be cleaned up. rts2800_fpu32.lib can be removed from the list as the libc.a will end up becoming that same library. libc.a is special. When libc.a is included the linker automatically figures out which runtime support library to include based on the build options specified.
One thing I noticed is that I am building for f28379 and you are building for f28335. I will clear out my workspace and start again with f28335 and see if that makes a difference for me.
Regards,
John
Are you running on F28379 or F28335? In the last post you mentioned 28335 and the linker command file is for 28335 but when I look at the build output from the post before that I see:
i"C:/ti/C2000Ware_1_00_05_00_Software/device_support/f2837xd/common/cmd" -i"C:/ti/C2000Ware_1_00_05_00_Software/device_support/f2837xd/headers/cmd" --reread_libs --display_error_number --xml_link_info="adc_epwm_cpu01_linkInfo.xml" --rom_model -o "adc_epwm_cpu01.out" "./F2837xD_CodeStartBranch.obj" "./F2837xD_DefaultISR.obj" "./F2837xD_EPwm.obj" "./F2837xD_GlobalVariableDefs.obj" "./F2837xD_Gpio.obj" "./F2837xD_Ipc.obj" "./F2837xD_PieCtrl.obj" "./F2837xD_PieVect.obj" "./F2837xD_SysCtrl.obj" "./F2837xD_usDelay.obj" "./adc_epwm_cpu01.obj" -lrts2800_fpu32.lib -l2837xD_RAM_lnk_cpu1.cmd -lF2837xD_Headers_nonBIOS_cpu1.cmd
I want to start from scratch and get exactly what you have setup. Please let me know the device you are using and the example and I will import that exact one. Right now I think I have something different.
Regards,
John
Saleh,
Normally for our example projects they will refer to the software package and you can just change the version of the package and it will automatically update. When I look at this example it is setup differently.
When I look at the include paths for the compiler and linker I see references to ${INSTALLROOT_F2837XD}. This variable is being resolved to the location of C2000Ware (see the tooltip popup in the capture).
I would bet that this variable is being defined when we import the example project. So to move to a different version of the software we would need to update the variable. You can do that here:
If I change this to be the location of the newer C2000Ware with /device_support/f2837xd on the end
Then I see that a lot of the files in the project are linked files (i.e. the files live inside the software package). So we need to update the location where they are Pointing as well here:
Now when I build I can see that everything is being pulled from the newer C2000Ware.
If you haven't modified anything in the example it may be easier to just delete the existing project from your workspace and import the new one from Resource Explorer.
I will be out of the office for the next week and a half and will not have internet access. If you need further help on this it would be best to start a new thread and the team will see that and pick it up. You can always reference this thread so that they have the context.
Regards,
John