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.
I recently converted an old Code Composer Project file to CCS 5 and when I go to build it, I get the following error.
error #16008-D: file ".../rts2812_ml.lib<exit.obj>" specifies ISA revision "C2700", which is not compatible with ISA revision "C2800" specified in a previous file or on the command line
The warning message that appears right before this error message (i.e. the previous line) is as follows:
warning #16002-D: build attribute vendor section TI missing in ".../rts2812_ml.lib<exit.obj>": compatibility cannot be determined
This is my first foray into embedded programming so any help here would be greatly appreciated.
Hi Dave,
C27x is not supported by v5. The last version to have support was CCSv3. Sorry.
ki
Unfortunately not! It does look like CCS v3 is still available for purchase (from here: http://www.ti.com/tool/ccstudio3). Since you make no mention of CCS v4, can I assume that I will have the same error using CCS v4 also?
David Burke1 said:It does look like CCS v3 is still available for purchase (from here: http://www.ti.com/tool/ccstudio3).
Actually it is better to buy a v5 license because anyone who buys a v5 full license gets a full license for v3 and v4 included. A full v5 license is the same price and you get support all TI devices.
CCSv4 does not have support for c27x either. Actually the C2000 compiler in v4 has support for C27x. But there is no CCS IDE support (CCS project support, CCS debug support).
One last question! Can you confirm for sure that CCS v3 will fully support "TMS320F2812PGFS". I think the original project was done with Code Composer Studio v2. I just want to make sure if I buy a license that I can build my code.
CCSv3 supports 2812. So does CCSv4 and v5.
What device are you using? Are you trying to migrate a 27x project to 28x?
Ok, you'll have to forgive me a little. Keep in mind my original comment about "This being my first foray into embedded programming". I know that we have two main chips the 2812 and a 6711, which we have always used. All I am trying to do is get the original source code / project (developed by someone else) to build so I can make some changes. So I would say that there is no migration happening here, just simply trying to build code that was probably originally built with CSS v2. I guess this is why I was confused about the error message in my first post. I couldn't understand the reference to C2700 relative to the library file rts2812_ml.lib.
Thank you so much for your support thus far!
David Burke1 said:I know that we have two main chips the 2812 and a 6711, which we have always used.
v5 supports both.
If that was originally a 28x project, I'm not sure where the 27x reference is coming from. I'd have to take a look at the project. Would it be possible to project the project (or a small reproducible test case)?
Thanks
ki
David Burke1 said:error #16008-D: file ".../rts2812_ml.lib<exit.obj>" specifies ISA revision "C2700", which is not compatible with ISA revision "C2800" specified in a previous file or on the command line
This message suggests that exit.obj in rts2812_ml.lib has a ISA revision of "C2700" instead of "C2800", and is throwing an error because object files with different ISAs are being combined in the link. From the name of the library I assume this is a custom runtime library (since the name of the default one is rts2800_ml.lib). My guess is that when a source file in the library, like exit.c, was rebuilt, the -v28 compiler option was missed. This would cause it to be built for "C2700" instead of "C2800".
One way to confirm this is to run the executable ofd2000 on the .lib file, redirect the output to a file and view it. The ofd2000 can be found in the \bin folder of your compiler toolset. The output of ofd2000 will show the CPU generation for each of the .obj files in the rts lib and you can verify which ones are C2700. You would then need to rebuild those files with -v28 compiler option and then rebuild the runtime library.
The C28x User Guides which will help with more details can be found here: http://processors.wiki.ti.com/index.php/TI_Compiler_Information#Compiler_Manuals
Ok. I did as you suggested and found out that every .obj file in rts2812_ml.lib used the c2700 for "CPU Generation". I am still very confused, because I took the original project and imported it into CCS v5. This original project compiled perfectly the last time it was built by the originally developer several years ago using an older version of CCS. Nothing has been changed except I am trying to build this on a new computer with CCS v5. All of the project files have been copied over in their original form and directory structure. If all of the project settings are the same (as they would be from an import) and all of the source files (including .lib's, etc) are the same, how was anyone able to get this project to build when that lib was built with C2700? I'm not sure if this helps or not but I have decided to put a copy of the original project file below, hoping you might see something there that could be causing this problem.
; Code Composer Project File, Version 2.0 (do not modify or remove this line)
[Project Settings]
ProjectName="DSP28"
ProjectDir="C:\ti2000\myprojects\Current\ppcPrimary4.06\"
ProjectType=Executable
CPUFamily=TMS320C28XX
Tool="Compiler"
Tool="Linker"
Config="PCMC_DAC_DEBUG"
Config="PCMC_DAC_FLASH"
Config="PCMC_DEBUG"
Config="PCMC_RELEASE"
Config="PCMC_RELEASE_NB"
Config="PPMC_DAC_DEBUG"
Config="PPMC_DAC_FLASH"
Config="PPMC_DEBUG"
Config="PPMC_RELEASE"
Config="PPMC_RELEASE_NB"
[Source Files]
Source="lib\rts2812_ml.lib"
Source="src\boot2812.asm"
Source="src\DSP28_Adc.c"
Source="src\DSP28_CpuTimers.c"
Source="src\DSP28_DefaultIsr.c"
Source="src\DSP28_Ev.c"
Source="src\DSP28_GlobalVariableDefs.c"
Source="src\DSP28_Gpio.c"
Source="src\DSP28_Mcbsp.c"
Source="src\DSP28_PieCtrl.c"
Source="src\DSP28_PieVect.c"
Source="src\DSP28_Scia.c"
Source="src\DSP28_Scib.c"
Source="src\DSP28_Spi.c"
Source="src\DSP28_SysCtrl.c"
Source="src\DSP28_Xintf.c"
Source="src\DSP28_XIntrupt.c"
Source="src\flashstart.asm"
Source="src\PPMC_Buzzer.c"
Source="src\PPMC_CommandTerminal.c"
Source="src\PPMC_Contactor.c"
Source="src\PPMC_DataDisplayAPI.c"
Source="src\PPMC_DataDump.c"
Source="src\PPMC_DPRAM.c"
Source="src\PPMC_EEPROM.c"
Source="src\PPMC_Faults.c"
Source="src\PPMC_FLASH.c"
Source="src\PPMC_Init.c"
Source="src\PPMC_Main.c"
Source="src\PPMC_paramTable.c"
Source="src\PPMC_RTC.c"
Source="src\PPMC_spiADC.c"
Source="src\PPMC_UIB.c"
Source="src\PPMC_UserInterface.c"
Source="cmd\PPMC.cmd"
["PCMC_DAC_DEBUG" Settings]
InitialBuildCmd=copy .\cmd\PPMC_TMX320F2812.cmd .\cmd\ppmc.cmd
["PCMC_DAC_FLASH" Settings]
InitialBuildCmd=copy.\cmd\PCMC_TMX320F2812_Boot.cmd .\cmd\ppmc.cmd
FinalBuildCmd=cd Out\PCMC_DAC_FLASH
FinalBuildCmd=hex2000 pcmchex.cmd
FinalBuildCmd=hex2ppc F2812APvCD.hex
["PCMC_DEBUG" Settings]
InitialBuildCmd=copy .\cmd\PPMC_TMX320F2812.cmd .\cmd\ppmc.cmd
["PCMC_RELEASE" Settings]
InitialBuildCmd=copy.\cmd\PCMC_TMX320F2812_Boot.cmd .\cmd\ppmc.cmd
FinalBuildCmd=cd Out\PCMC_RELEASE
FinalBuildCmd=hex2000 pcmchex.cmd
FinalBuildCmd=hex2ppc F2812APvC.hex
["PCMC_RELEASE_NB" Settings]
InitialBuildCmd=copy.\cmd\PCMC_TMX320F2812_New_Boot.cmd .\cmd\ppmc.cmd
FinalBuildCmd=cd Out\PCMC_RELEASE_NB
FinalBuildCmd=hex2000 pcmchexNewBoot.cmd
FinalBuildCmd=hex2ppc2 pri__APvCN.hex
["PPMC_DAC_DEBUG" Settings]
InitialBuildCmd=copy .\cmd\PPMC_TMX320F2812.cmd .\cmd\ppmc.cmd
["PPMC_DAC_FLASH" Settings]
InitialBuildCmd=copy.\cmd\PPMC_TMX320F2812_Boot.cmd .\cmd\ppmc.cmd
FinalBuildCmd=cd Out\PPMC_DAC_FLASH
FinalBuildCmd=hex2000 ppmchexDac.cmd
FinalBuildCmd=hex2ppc F2812APvPdac.hex
["PPMC_DEBUG" Settings]
InitialBuildCmd=copy .\cmd\PPMC_TMX320F2812.cmd .\cmd\ppmc.cmd
["PPMC_RELEASE" Settings]
InitialBuildCmd=copy.\cmd\PPMC_TMX320F2812_Boot.cmd .\cmd\ppmc.cmd
FinalBuildCmd=cd Out\PPMC_RELEASE
FinalBuildCmd=hex2000 ppmchex.cmd
FinalBuildCmd=hex2ppc F2812APvP.hex
["PPMC_RELEASE_NB" Settings]
InitialBuildCmd=copy.\cmd\PPMC_TMX320F2812_New_Boot.cmd .\cmd\ppmc.cmd
FinalBuildCmd=cd Out\PPMC_RELEASE_NB
FinalBuildCmd=hex2000 ppmchexNewBoot.cmd
FinalBuildCmd=hex2ppc2P PRI__APvPN.hex
["Compiler" Settings: "PCMC_DAC_DEBUG"]
Options=-g -k -q -pr -ad_DEBUG=1 -ad_RELEASE=0 -as -fr"C:\ti2000\myprojects\Current\ppcPrimary4.06\Out\PCMC_DAC_DEBUG\Obj" -fs"C:\ti2000\myprojects\Current\ppcPrimary4.06\Asm" -i"..\..\include" -i"..\include" -d"LARGE_MODEL" -d"_PCMC_" -d"_DAC_" -u"_PPMC_" -ml -mt -v28
["Compiler" Settings: "PCMC_DAC_FLASH"]
Options=-g -k -q -ad_DEBUG=0 -ad_RELEASE=1 -as -fr"C:\ti2000\myprojects\Current\ppcPrimary4.06\Out\PCMC_DAC_FLASH\Obj" -fs"C:\ti2000\myprojects\Current\ppcPrimary4.06\Asm" -i"C:\ti2000\myprojects\Current\ppcPrimary4.06\include" -d"LARGE_MODEL" -d"_PCMC_" -d"_DAC_" -u"_PPMC_" -ml -v28
["Compiler" Settings: "PCMC_DEBUG"]
Options=-g -k -q -pr -ad_DEBUG=1 -ad_RELEASE=0 -as -fr"C:\ti2000\myprojects\Current\ppcPrimary4.06\Out\PCMC_DEBUG\Obj" -fs"C:\ti2000\myprojects\Current\ppcPrimary4.06\Asm" -i"..\..\include" -i"..\include" -d"LARGE_MODEL" -d"_PCMC_" -u"_PPMC_" -u"_DAC_" -ml -mt -v28
["Compiler" Settings: "PCMC_RELEASE"]
Options=-k -q -ad_DEBUG=0 -ad_RELEASE=1 -as -fr"C:\ti2000\myprojects\Current\ppcPrimary4.06\Out\PCMC_RELEASE\Obj" -fs"C:\ti2000\myprojects\Current\ppcPrimary4.06\Asm" -i"C:\ti2000\myprojects\Current\ppcPrimary4.06\include" -d"LARGE_MODEL" -d"_PCMC_" -u"_PPMC_" -u"_DAC_" -ml -v28
["Compiler" Settings: "PCMC_RELEASE_NB"]
Options=-g -k -q -ad_DEBUG=0 -ad_RELEASE=1 -as -fr"C:\ti2000\myprojects\Current\ppcPrimary4.06\Out\PCMC_RELEASE_NB\Obj" -fs"C:\ti2000\myprojects\Current\ppcPrimary4.06\Asm" -i"C:\ti2000\myprojects\Current\ppcPrimary4.06\include" -d"LARGE_MODEL" -d"_PCMC_" -u"_PPMC_" -u"_DAC_" -ml -v28
["Compiler" Settings: "PPMC_DAC_DEBUG"]
Options=-g -k -q -ad_DEBUG=1 -ad_RELEASE=0 -as -fr"C:\ti2000\myprojects\Current\ppcPrimary4.06\Out\PPMC_DAC_DEBUG\Obj" -fs"C:\ti2000\myprojects\Current\ppcPrimary4.06\Asm" -i"..\..\include" -i"..\include" -d"LARGE_MODEL" -d"_PPMC_" -d"_DAC_" -u"_PCMC_" -ml -mt -v28
["Compiler" Settings: "PPMC_DAC_FLASH"]
Options=-g -k -q -ad_DEBUG=0 -ad_RELEASE=1 -as -fr"C:\ti2000\myprojects\Current\ppcPrimary4.06\Out\PPMC_DAC_FLASH\Obj" -fs"C:\ti2000\myprojects\Current\ppcPrimary4.06\Asm" -i"C:\ti2000\myprojects\Current\ppcPrimary4.06\include" -d"LARGE_MODEL" -d"_PPMC_" -d"_DAC_" -u"_PCMC_" -ml -v28
["Compiler" Settings: "PPMC_DEBUG"]
Options=-g -k -q -ad_DEBUG=1 -ad_RELEASE=0 -as -fr"C:\ti2000\myprojects\Current\ppcPrimary4.06\Out\PPMC_DEBUG\Obj" -fs"C:\ti2000\myprojects\Current\ppcPrimary4.06\Asm" -i"..\..\include" -i"..\include" -d"LARGE_MODEL" -d"_PPMC_" -u"_DAC_" -u"_PCMC_" -ml -mt -v28
["Compiler" Settings: "PPMC_RELEASE"]
Options=-g -k -q -ad_DEBUG=0 -ad_RELEASE=1 -as -fr"C:\ti2000\myprojects\Current\ppcPrimary4.06\Out\PPMC_RELEASE\Obj" -fs"C:\ti2000\myprojects\Current\ppcPrimary4.06\Asm" -i"C:\ti2000\myprojects\Current\ppcPrimary4.06\include" -d"LARGE_MODEL" -d"_PPMC_" -u"_DAC" -u"_PCMC_" -ml -v28
["Compiler" Settings: "PPMC_RELEASE_NB"]
Options=-g -k -q -ad_DEBUG=0 -ad_RELEASE=1 -as -fr"C:\ti2000\myprojects\Current\ppcPrimary4.06\Out\PPMC_RELEASE_NB\Obj" -fs"C:\ti2000\myprojects\Current\ppcPrimary4.06\Asm" -i"C:\ti2000\myprojects\Current\ppcPrimary4.06\include" -d"LARGE_MODEL" -d"_PPMC_" -u"_DAC" -u"_PCMC_" -ml -v28
["Linker" Settings: "PCMC_DAC_DEBUG"]
Options=-q -c -m".\Out\PCMC_DAC_DEBUG\pcmcRamDac.map" -o".\Out\PCMC_DAC_DEBUG\pcmcRamDac.out" -x
["Linker" Settings: "PCMC_DAC_FLASH"]
Options=-q -c -m".\Out\PCMC_DAC_FLASH\pcmcFlashDac.map" -o".\Out\PCMC_DAC_FLASH\pcmcFlashDac.out" -x
["Linker" Settings: "PCMC_DEBUG"]
Options=-q -c -m".\Out\PCMC_DEBUG\pcmcRam.map" -o".\Out\PCMC_DEBUG\pcmcRam.out" -x
["Linker" Settings: "PCMC_RELEASE"]
Options=-q -c -m".\Out\PCMC_RELEASE\pcmcFlash.map" -o".\Out\PCMC_RELEASE\pcmcFlash.out" -x
["Linker" Settings: "PCMC_RELEASE_NB"]
Options=-q -c -m".\Out\PCMC_RELEASE_NB\pcmcFlash.map" -o".\Out\PCMC_RELEASE_NB\pcmcFlash.out" -x
["Linker" Settings: "PPMC_DAC_DEBUG"]
Options=-q -c -m".\Out\PPMC_DAC_DEBUG\ppmcRamDac.map" -o".\Out\PPMC_DAC_DEBUG\ppmcRamDac.out" -x
["Linker" Settings: "PPMC_DAC_FLASH"]
Options=-q -c -m".\Out\PPMC_DAC_FLASH\ppmcFlashDac.map" -o".\Out\PPMC_DAC_FLASH\ppmcFlashDac.out" -x
["Linker" Settings: "PPMC_DEBUG"]
Options=-q -c -m".\Out\PPMC_DEBUG\ppmcRam.map" -o".\Out\PPMC_DEBUG\ppmcRam.out" -x
["Linker" Settings: "PPMC_RELEASE"]
Options=-q -c -m".\Out\PPMC_RELEASE\ppmcFlash.map" -o".\Out\PPMC_RELEASE\ppmcFlash.out" -x
["Linker" Settings: "PPMC_RELEASE_NB"]
Options=-q -c -m".\Out\PPMC_RELEASE_NB\ppmcFlash.map" -o".\Out\PPMC_RELEASE_NB\ppmcFlash.out" -x
["src\boot2812.asm" Settings: "PCMC_DAC_FLASH"]
Options="Compiler" +{-d"_RELEASE"}
["src\boot2812.asm" Settings: "PCMC_RELEASE"]
Options="Compiler" +{-d"_RELEASE"}
["src\boot2812.asm" Settings: "PCMC_RELEASE_NB"]
Options="Compiler" +{-d"_RELEASE"}
["src\boot2812.asm" Settings: "PPMC_DAC_FLASH"]
Options="Compiler" +{-d"_RELEASE"}
["src\boot2812.asm" Settings: "PPMC_RELEASE"]
Options="Compiler" +{-d"_RELEASE"}
["src\boot2812.asm" Settings: "PPMC_RELEASE_NB"]
Options="Compiler" +{-d"_RELEASE"}
David,
OK, I did some more testing with different versions of the compiler tools and below is a summary of what I found. Basically I did a simple test of compiling/linking any example code with rts2800_ml.lib and rts2700_ml.lib with different versions of toolsets. So a simple command line like the following:
cl2000 -g -ml -v28 main.c -z -c -l rts2800_ml.lib
cl2000 -g -ml -v28 main.c -z -c -l rts2700_ml.lib
Notice that the main.c is built with -v28, hence when linking with rts2700_ml.lib it would be linking with a different ISA. I believe this simulates the environment you are working with.
The older version of the compiler tools v4.1.x (which is included in CCS 3.3) did not generate an error when mixing ISAs as in the second command above.
However, starting with compiler tools v5.1.0 and higher an error is generated. It looks like it was just something that was overlooked in the earlier versions of the tools, and the linker allowed the build to complete, while the newer tools have this check added in.
Your options for moving forward are the following:
1) Try using the CGT 4.1.x with CCSv5. The steps to install and have CCS detect a different version of the compiler are described in this page: http://processors.wiki.ti.com/index.php/Compiler_Installation_and_Selection. Note, however that this combination of CGT/CCS is not supported/tested since that is a pretty old version of the compiler. Also, even though this version of compiler does not generate the error for mixing ISAs, I dont know what the implications of that might be - problems at runtime etc. So I would be careful about going down this path, but if the earllier build was a known working/validated build, you could try this option.
2) Update to CCSv5 and use the latest CGT. In this case, if you need the custom runtime library for your project, you would need to rebuild the library for "c2800" ISA. Assuming you have the sources for the library, this can be done. Or if the custom runtime library is not really needed, you can use the default one provided with the compiler tools.
Hope this clears things up a little.
Making progress! I am working with your "option 1" suggestion and I no longer get the error I was getting before. All of the source files compile but during the linking stage I get the messages shown below. Not sure if I should be concerned with the warnings or just the errors.
<Linking>
>> warning: creating output section sys2 without SECTIONS specification
>> warning: creating .stack section with default size of 400 (hex) words.
Use
-stack option to change the default size.
>> warning: creating .sysmem section with default size of 400 (hex) words.
Use -heap option to change the default size.
>> warning: load address of uninitialized section event ignored
>> warning: load address of uninitialized section .const ignored
>> error: can't allocate .econst, size 000093ad (page 0) in FLASH_DRAMEXT
(avail: 000086d0)
>> error: can't allocate .cinit, size 00003121 (page 0) in FLASH_PRAMEXT3
(avail: 00002ff0)
>> error: errors in input - C:/Users/burked/Documents/Code
Composer/PowerThru/14091-119_rW/ppcPrimary4.06/ppcPrimary/../Out/PCMC_RELEASE/pcmcFlash.out not built
For reference purposes, the "Linker" section of the project file for this build configuration is as follows:
["Linker" Settings: "PCMC_RELEASE"]
Options=-q -c -m".\Out\PCMC_RELEASE\pcmcFlash.map" -o".\Out\PCMC_RELEASE\pcmcFlash.out" -x
So I took a look at the pcmcFlash.map file that gets generated by the Linker (as specified in the previous line here) and the top section of it includes the following which is where the "FLASH_DRAMEXT" and "FLASH_PRAMEXT3" come from in the Linker error message shown above
******************************************************************************
TMS320C2000 COFF Linker PC v4.1.4
******************************************************************************
>> Linked Tue Oct 02 14:29:17 2012
OUTPUT FILE NAME: <C:/Users/burked/Documents/Code Composer/PowerThru/14091-119_rW/ppcPrimary4.06/ppcPrimary/../Out/PCMC_RELEASE/pcmcFlash.out>
ENTRY POINT SYMBOL: "_c_int00" address: 003f0000
MEMORY CONFIGURATION
name origin length used attr fill
---------------------- -------- --------- -------- ---- --------
PAGE 0: PRAML0 00008000 00002000 00001c2a RWIX
PRAMEXT 00100000 00010000 0000f63f RWIX
PRAMEXT2 00110000 00002000 000012d5 RWIX
EXT_RAM_1 00112000 00004000 00000000 RWIX
EXT_RAM_2 00116000 00004000 00000000 RWIX
EXT_RAM_3 0011a000 00003000 00000000 RWIX
EXT_FLASH_1 00170000 00004000 00000000 RWIX
EXT_FLASH_2 00174000 00004000 00000000 RWIX
EXT_FLASH_3 00178000 00003000 00000000 RWIX
FLASH_DRAMINT 003d8000 00000010 00000002 RWIX
FLASH_PRAMEXT 003d8010 0000f920 0000f63f RWIX
FLASH_DRAMEXT 003e7930 000086d0 00000000 RWIX
FLASHBOOT 003f0000 00000150 0000011e RWIX
FLASH_PRAMINT 003f0150 00001000 00000b79 RWIX
FLASH_PRAML0 003f1150 00001fb0 00001c2a RWIX
FLASH_PRAMEXT2 003f3100 00001f00 000012d5 RWIX
FLASH_PRAMEXT3 003f5000 00002ff0 00001161 RWIX
FLASHJUMP 003f7ff6 00000002 00000002 RWIX
PRAMH0 003f8000 00001000 00000b79 RWIX
David Burke1 said:>> error: can't allocate .econst, size 000093ad (page 0) in FLASH_DRAMEXT
(avail: 000086d0)
>> error: can't allocate .cinit, size 00003121 (page 0) in FLASH_PRAMEXT3
(avail: 00002ff0)
These errors are saying that the size of the sections .econst and .cinit are too large for them to fit into the memory regions that they are allocated to. Basically in the linker command file (.cmd) there will be a SECTIONS specification which tells the linker where to allocate the different sections. In this case, these two sections are not able to fit into the available memory in the specified regions. Some more general information on this can be found here: http://processors.wiki.ti.com/index.php/C28x_Compiler_-_Understanding_Linking
Do you know which version of the compiler was used when the project was originally built successfully? It is possible that different versions of the compiler tools produce slightly different sizes of sections, so that could be the case here if the original project was built with a different version of the toolset. If so, you would need to adjust the linker command file to get around the errors.
David Burke1 said:>> warning: creating output section sys2 without SECTIONS specification
This warning is saying that your code creates a output section named sys2 but that section is not being allocated explicitly within the SECTIONS directive in the linker command file. In such cases, the linker will do some default allocation but that may or may not have adverse effects. It is advisable to add a directive in the linker command file to allocate that section to an appropriate memory region.
David Burke1 said:>> warning: creating .stack section with default size of 400 (hex) words.
Use
-stack option to change the default size.
>> warning: creating .sysmem section with default size of 400 (hex) words.
Use -heap option to change the default size.
This warning is simply saying that the .stack and .sysmem (heap) sections are being created with default sizes. This should be ok to ignore but if you're application has requirements that need more stack or heap, you should change those sizes using linker options as suggested in the warning message.
I believe that the project was originally created and built with either Code Composer Studio v2 or v3. I have found a copy of v3 on another computer but when I go to open the project, I get the following error.
When I go to "Code Composer Studio Component Manager" It doesn't show the Build Tools for the 28xx (TMS320F28xx). Unfortunately we do not have the original PC that this project was built with. How do I go about getting (and installing) the Build Tools for the 28xx (TMS320F28xx)? Once I have them I can try building with CCS v3. FYI, in "Code Composer Studio Component Manager", I right clicked on Build Tools then selected Web -> Update Now and the only options I see are for C6000.
I am curious to know your recommendation at this point. Thanks again for all your support.
The screenshot of the error message is missing.
In any case, I'm not sure that going down the path of installing the Build Tools for 28xx is a good investment of time at this point. If the original project was checked in some sort of version control system and you have access to the linker map file (.map) you should be able to look there for the version of compiler tools used for the build. An ofd2000 dump of the .out file might show it as well.
My recommendation to move forward would be to stay with CCSv5 and update it as necessary to get the project to build. Unless your requirement is to produce the exact same output as the original project (in which case the exact same compiler tools would need to be used), the best option would be to move forward with CCSv5. You might even consider creating a new project from scratch (rather than migrating the CCSv2/3 project) and adding all the source files to it so you have a new clean build.
There are many resources available that can help with getting started with CCSv5, both included with the tools as well as on the wiki: http://processors.wiki.ti.com/index.php/Category:Code_Composer_Studio_v5
I am now thinking that the fix to my problem using CCS v4 or v5 is to change the stack size from the default of 400 hex (shown in the build error message previously posted and shown below). Since 400 hex is the default with CCS v4, can you tell me what it is/was for CCS v3? It would seem like if 400 Hex was larger than that which was used in CCS v3, that would explain the "can't allocate" errors below. What do you think?
>> warning: creating .stack section with default size of 400 (hex) words.
Use
-stack option to change the default size.
>> warning: creating .sysmem section with default size of 400 (hex) words.
Use -heap option to change the default size.
>> warning: load address of uninitialized section event ignored
>> warning: load address of uninitialized section .const ignored
>> error: can't allocate .econst, size 000093ad (page 0) in FLASH_DRAMEXT
(avail: 000086d0)
>> error: can't allocate .cinit, size 00003121 (page 0) in FLASH_PRAMEXT3
(avail: 00002ff0)
David Burke1 said:It would seem like if 400 Hex was larger than that which was used in CCS v3, that would explain the "can't allocate" errors below
That depends on where the .stack section is allocated. Can you attach the linker command file (.cmd) and link map file (.map)?
If you have access to these files from the original build it would be even better so you can compare the two.
/**************************************************************************** * * Copyright 2003 Pentadyne Power Corporation. All Rights Reserved Worldwide. * * $Author: Steves $ * * $History: pcmchex.cmd $ * * ***************** Version 1 ***************** * User: Steves Date: 8/30/07 Time: 11:11a * Created in $/Software/Users/SteveS/2812/application/PPCPRIMARY3.15.15/Out/PCMC_RELEASE * include EEINIT ROT and new time/date formats for _GETDATA * is CCS v3.3 and v2.0 compatible * * ***************** Version 1 ***************** * User: Steves Date: 8/10/07 Time: 11:53a * Created in $/Software/Users/SteveS/2812/application/PPCPRIMARY3.15.10/Out/PCMC_RELEASE * * ***************** Version 1 ***************** * User: Steves Date: 8/09/07 Time: 1:52p * Created in $/Software/Users/SteveS/2812/application/ppcprimary3.15.08/Out/PCMC_RELEASE * JaeDo version with OvrSpd /OvrCurr problem correction * * ***************** Version 1 ***************** * User: Jaedop Date: 7/18/07 Time: 5:29p * Created in $/Software/Firmware/_Primary/UnderDev/ppcPrimary3.15.03/Out/PCMC_RELEASE * * ***************** Version 1 ***************** * User: Steves Date: 7/18/07 Time: 3:50p * Created in $/Software/Users/SteveS/2812/application/PPCPRIMARY3.15.02/Out/PCMC_RELEASE * * ***************** Version 1 ***************** * User: Jaedop Date: 7/18/07 Time: 2:55p * Created in $/Software/Firmware/_Primary/UnderDev/ppcPrimary3.15.01/Out/PCMC_RELEASE * * ***************** Version 1 ***************** * User: Jaedop Date: 7/18/07 Time: 10:08a * Created in $/Software/Firmware/_Primary/application/ppcPrimary3.15/Out/PCMC_RELEASE * ****************************************************************************/ pcmcFLASH.out -m -image -memwidth 16 -map pcmchexC.map ROMS { FLASH : origin = 0x3D8000, length = 0x01fff8, romwidth = 16 files = {F2812APvC.hex} }
Attached are the two files renamed for uploading to this site.
David,
The .cmd file attached is not the linker command file I was looking for, but rather the command file used with the hex converter. There must be other .cmd files (that contain MEMORY and SECTIONS directives in them) that are part of the project.
In any case, looking at the .map file, it seems that the version of compiler tools used for the build is 3.01. This is an extremely old version (>10 years) and is likely the version that came with CCSv2, which has not been supported for a long time.
As I mentioned before, my suggestion at this point would be to migrate the project to newer versions of the tools and make any necessary updates to get it to build and work with the latest tools.
/**************************************************************************** * * $Archive: /Software/Users/SteveS/2812/application/PPCPRIMARY3.15.10/cmd/PCMC_TMX320F2812_Boot.cmd $ * * Copyright 2003 Pentadyne Power Corporation. All Rights Reserved Worldwide. * * $Author: Steves $ * * $History: PCMC_TMX320F2812_Boot.cmd $ * * ***************** Version 1 ***************** * User: Steves Date: 8/10/07 Time: 11:51a * Created in $/Software/Users/SteveS/2812/application/PPCPRIMARY3.15.10/cmd * * ***************** Version 1 ***************** * User: Steves Date: 8/09/07 Time: 1:43p * Created in $/Software/Users/SteveS/2812/application/ppcprimary3.15.08/cmd * JaeDo version with OvrSpd /OvrCurr problem correction * * ***************** Version 1 ***************** * User: Jaedop Date: 7/18/07 Time: 5:27p * Created in $/Software/Firmware/_Primary/UnderDev/ppcPrimary3.15.03/cmd * * ***************** Version 1 ***************** * User: Steves Date: 7/18/07 Time: 3:47p * Created in $/Software/Users/SteveS/2812/application/PPCPRIMARY3.15.02/cmd * * ***************** Version 1 ***************** * User: Jaedop Date: 7/18/07 Time: 2:53p * Created in $/Software/Firmware/_Primary/UnderDev/ppcPrimary3.15.01/cmd * * ***************** Version 1 ***************** * User: Jaedop Date: 7/18/07 Time: 9:45a * Created in $/Software/Firmware/_Primary/application/ppcPrimary3.15/cmd * ****************************************************************************/ MEMORY { PAGE 0 : PRAML0 : origin = 0x008000, length = 0x002000 PRAMH0 : origin = 0x3f8000, length = 0x001000 PRAMEXT : origin = 0x100000, length = 0x010000 PRAMEXT2 : origin = 0x110000, length = 0x002000 EXT_RAM_1 : origin = 0x112000, length = 0x004000 EXT_RAM_2 : origin = 0x116000, length = 0x004000 EXT_RAM_3 : origin = 0x11A000, length = 0x003000 EXT_FLASH_1 : origin = 0x170000, length = 0x004000 EXT_FLASH_2 : origin = 0x174000, length = 0x004000 EXT_FLASH_3 : origin = 0x178000, length = 0x003000 FLASH_DRAMINT : origin = 0x3D8000, length = 0x000010 FLASH_PRAMEXT : origin = 0x3D8010, length = 0x00F920 FLASH_DRAMEXT : origin = 0x3E7930, length = 0x0086D0 FLASHBOOT : origin = 0x3F0000, length = 0x000150 FLASH_PRAMINT : origin = 0x3F0150, length = 0x001000 FLASH_PRAML0 : origin = 0x3F1150, length = 0x001FB0 FLASH_PRAMEXT2 : origin = 0x3F3100, length = 0x001F00 FLASH_PRAMEXT3 : origin = 0x3F5000, length = 0x002FF0 FLASHJUMP : origin = 0x3F7FF6, length = 0x000002 PAGE 1 : /* SARAM */ RAMM0 : origin = 0x000000, length = 0x000400 RAMM1 : origin = 0x000400, length = 0x000400 /* SARAM */ DRAMH0 : origin = 0x3f9000, length = 0x001000 /* External SRAM */ DRAMEXT : origin = 0x140000, length = 0x020000 /* External DPRAM */ SEMAPHORES : origin = 0x002000, length = 0x001000 DPRAM : origin = 0x003000, length = 0x000FFE DPRAM_MAILBOX : origin = 0x003FFE, length = 0x000002 LEDBAR : origin = 0x004000, length = 0x001000 DAC : origin = 0x005000, length = 0x001000 /* Peripheral Frame 0: */ DEV_EMU : origin = 0x000880, length = 0x000180 FLASH_REGS : origin = 0x000A80, length = 0x000060 CSM : origin = 0x000AE0, length = 0x000010 XINTF : origin = 0x000B20, length = 0x000020 CPU_TIMER0 : origin = 0x000C00, length = 0x000008 CPU_TIMER1 : origin = 0x000C08, length = 0x000008 CPU_TIMER2 : origin = 0x000C10, length = 0x000008 PIE_CTRL : origin = 0x000CE0, length = 0x000020 PIE_VECT : origin = 0x000D00, length = 0x000100 /* Peripheral Frame 1: */ ECAN_A : origin = 0x006000, length = 0x000100 ECAN_AMBOX : origin = 0x006100, length = 0x000100 /* Peripheral Frame 2: */ SYSTEM : origin = 0x007010, length = 0x000020 SPI_A : origin = 0x007040, length = 0x000010 SCI_A : origin = 0x007050, length = 0x000010 XINTRUPT : origin = 0x007070, length = 0x000010 GPIOMUX : origin = 0x0070C0, length = 0x000020 GPIODAT : origin = 0x0070E0, length = 0x000020 ADC : origin = 0x007100, length = 0x000020 EV_A : origin = 0x007400, length = 0x000040 EV_B : origin = 0x007500, length = 0x000040 SPI_B : origin = 0x007740, length = 0x000010 SCI_B : origin = 0x007750, length = 0x000010 MCBSP_A : origin = 0x007800, length = 0x000040 /* CSM Password Locations */ CSM_PWL : origin = 0x3F7FF8, length = 0x000008 } SECTIONS { /* Allocate program areas: */ .flashjump : > FLASHJUMP, PAGE = 0 .bootppmc : > FLASHBOOT, PAGE = 0 .reset : load = FLASH_PRAMINT, run = PRAMH0, PAGE = 0 "isr" : load = FLASH_PRAMINT, run = PRAMH0, PAGE = 0 "dd" : load = FLASH_PRAMINT, run = PRAMH0, PAGE = 0 "chipinit" : load = FLASH_PRAML0, run = PRAML0, PAGE = 0 "dpram" : load = FLASH_PRAML0, run = PRAML0, PAGE = 0 "eeprom" : load = FLASH_PRAML0, run = PRAML0, PAGE = 0 "uib" : load = FLASH_PRAML0, run = PRAML0, PAGE = 0 "flash" : load = FLASH_PRAML0, run = PRAML0, PAGE = 0 "ui" : load = FLASH_PRAML0, run = PRAML0, PAGE = 0 "adc" : load = FLASH_PRAML0, run = PRAML0, PAGE = 0 .text : load = FLASH_PRAMEXT, run = PRAMEXT, PAGE = 0 "sys" : load = FLASH_PRAMEXT, run = PRAMEXT, PAGE = 0 "ti" : load = FLASH_PRAMEXT, run = PRAMEXT, PAGE = 0 "uiM" : load = FLASH_PRAMEXT, run = PRAMEXT, PAGE = 0 .switch : load = FLASH_PRAMEXT2, run = PRAMEXT2, PAGE = 0 "ddapi" : load = FLASH_PRAMEXT2, run = PRAMEXT2, PAGE = 0 "event" : load = FLASH_PRAMEXT2, run = PRAMEXT2, PAGE = 0 "ti2" : load = FLASH_PRAMEXT2, run = PRAMEXT2, PAGE = 0 "spi" : load = FLASH_PRAMEXT2, run = PRAMEXT2, PAGE = 0 "contactor" : load = FLASH_PRAMEXT2, run = PRAMEXT2, PAGE = 0 "buzzer" : load = FLASH_PRAMEXT2, run = PRAMEXT2, PAGE = 0 "faults" : load = FLASH_PRAMEXT2, run = PRAMEXT2, PAGE = 0 "scia" : load = FLASH_PRAMEXT2, run = PRAMEXT2, PAGE = 0 "scib" : load = FLASH_PRAMEXT2, run = PRAMEXT2, PAGE = 0 "rtc" : load = FLASH_PRAMEXT2, run = PRAMEXT2, PAGE = 0 .cinit > FLASH_PRAMEXT3, PAGE = 0 /* Allocate data areas: */ .stack : > RAMM1, PAGE = 1 .sysmem : > RAMM0, PAGE = 1 .bss : > DRAMH0, PAGE = 1 .ebss : > DRAMEXT, PAGE = 1 /* .const : > DRAMEXT, PAGE = 1 */ .const : load = FLASH_DRAMEXT PAGE 0, run = DRAMEXT PAGE 1 { __const_run = .; /* *(.c_mark) *(.const) */ __const_length = . - __const_run; } /* .econst : > DRAMEXT, PAGE = 1 */ .econst : load = FLASH_DRAMEXT PAGE 0, run = DRAMEXT PAGE 1 { __econst_run = .; *(.ec_mark) *(.econst) __econst_length = . - __econst_run; } "uidata" : > DRAMEXT, PAGE 1 "ver" : load = FLASH_DRAMINT PAGE 0, run = DRAMEXT PAGE 1 /* Allocate Peripheral Frame 0 Register Structures: */ DevEmuRegsFile : > DEV_EMU, PAGE = 1 FlashRegsFile : > FLASH_REGS, PAGE = 1 CsmRegsFile : > CSM, PAGE = 1 XintfRegsFile : > XINTF, PAGE = 1 CpuTimer0RegsFile : > CPU_TIMER0, PAGE = 1 CpuTimer1RegsFile : > CPU_TIMER1, PAGE = 1 CpuTimer2RegsFile : > CPU_TIMER2, PAGE = 1 PieCtrlRegsFile : > PIE_CTRL, PAGE = 1 PieVectTable : > PIE_VECT, PAGE = 1 /* Allocate Peripheral Frame 2 Register Structures: */ ECanaRegsFile : > ECAN_A, PAGE = 1 ECanaMboxesFile : > ECAN_AMBOX PAGE = 1 /* Allocate Peripheral Frame 1 Register Structures: */ SysCtrlRegsFile : > SYSTEM, PAGE = 1 SpiaRegsFile : > SPI_A, PAGE = 1 SciaRegsFile : > SCI_A, PAGE = 1 XIntruptRegsFile : > XINTRUPT, PAGE = 1 GpioMuxRegsFile : > GPIOMUX, PAGE = 1 GpioDataRegsFile : > GPIODAT PAGE = 1 AdcRegsFile : > ADC, PAGE = 1 EvaRegsFile : > EV_A, PAGE = 1 EvbRegsFile : > EV_B, PAGE = 1 ScibRegsFile : > SCI_B, PAGE = 1 McbspaRegsFile : > MCBSP_A, PAGE = 1 /* CSM Password Locations */ CsmPwlFile : > CSM_PWL, PAGE = 1 SEMRegsFile : > SEMAPHORES, PAGE = 1 DPRAMRegsFile : > DPRAM, PAGE = 1 DPRAMMailboxRegsFile : > DPRAM_MAILBOX, PAGE = 1 LEDBarRegsFile : > LEDBAR, PAGE = 1 DACRegsFile : > DAC, PAGE = 1 }
Here is the correct linker command file.
Looking at the linker command file, I can tell that adjusting the size of stack and heap will not make the linking error go away. Notice that the .stack and .sysmem sections are in RAMM1, RAMM0 while the errors are coming from the allocation to FLASH_DRAMEXT and FLASH_PRAMEXT3. You would instead need to allocate .econst and .cinit to memory regions that have sufficient space for them (the error message tells you the size of the section and how much memory is available in the region to help understand this).
Ok. As it turns out I had the wrong configuration selected for the project I was working on. That error still applies to that configuration, but I now have a different configuration selected. Anyway, now that I have the correct project configuration selected I get another error which should be easy to fix. The error message is:
"hex2000' is not recognized as an internal or external command, operable program or batch file."
The compiler / linker is looking for a program called hex2000.exe, which I have found in the directory "C:\Program Files (x86)\Texas Instruments\ccsv4\tools\compiler\c2000\bin". By the way, for reference purposes I uninstalled all versions of CCS on my computer and then reinstalled only CCS v4. I think that this program simply converts the .out file to straight hex.
You can see in the "Settings" section of the original project file, it references this hex2000 program.
"PPMC_RELEASE_NB" Settings]
InitialBuildCmd=copy.\cmd\PPMC_TMX320F2812_New_Boot.cmd .\cmd\ppmc.cmd
FinalBuildCmd=cd Out\PPMC_RELEASE_NB
FinalBuildCmd=hex2000 ppmchexNewBoot.cmd
FinalBuildCmd=hex2ppc2P PRI__APvPN.hex
David Burke1 said:"hex2000' is not recognized as an internal or external command, operable program or batch file."
This error usually occurs when the path to hex2000 is not set.
Not sure what your project conversion from CCSv3 to v4 resulted in, but in CCSv4 the hex2000 step would usually be under "Post Build Step" in the project properties. On that command line, make sure the full path to hex2000 is specified.
Ok. We just purchased a full license for CCS v5. How do I get a copy of CCS v3, since you said that we also get a full license for v3. I do not see any download option for that version on the TI website.
David,
Could you please start a private conversation with me, so we can confirm your product registration with CCSv5 and then send you a download link for CCS 3.3?
To start a private conversation, simply click on my name to get to my Profile, you should see a link to Start Conversation on the right side of the page.
An update on this for those reading along. David was able to get a copy of CCS 3.3 and get a successful build of the project (but only after using the default rts2800_ml.lib instead of the custom rts2812_ml.lib - the reason for which is not clear).
Ok. I've come full circle and I'm back to this error again. Based on everything I know right now, it appears (based on the linker output map file) that "TMS320C2000 COFF Linker PC Version 3.01" was used to build this project successfully at one point in time several years ago. I cannot find the original source code to the rts2812_ml.lib so rebuilding it with the -v28 switch is not an option at this point. We now have a licensed copy of CCS v3.3, which I am using to try to build this project. Our version of CCS v3 uses "TMS320C2000 Linker PC v5.2.1" which I am hoping is the reason why I cannot build this but someone else could years ago using an earlier version of CCS v3. So the $64k question is: Can I get access to the "TMS320C2000 COFF Linker PC Version 3.01"? I can only assume at this point that this earlier version of the linker ignored this issue and allowed the build to complete.
David,
I'll send you a private message offline regarding the older code generation tools.
Ok. Using the latest CCS v3 compiler tools you provided, I no longer receive that error but I now get the errors shown below. If I add the original rts2800_ml.lib file to the project it builds clean all the way through but the output of that build does not work on our system which tells me that the rts2812_ml.lib file that is library that is supposed to be used. Do you have some thoughts on why I would be getting the error message (undefined symbol) shown below. I'm not sure if this helps or not but every version of this project that I find has both of the two library files (rts2812_ml.lib and rts2800_ml.lib) in the "lib" folder and "include" folder on the PC but non of them include rts2800_ml.lib in the actual CCS project.
[Linking...] "C:\CCStudio_v3.3PLA\C2000\cgtools\bin\cl2000" -@"PCMC_RELEASE_NB.lkf"
>> warning: load address of uninitialized section event ignored
>> warning: load address of uninitialized section .const ignored
undefined first referenced
symbol in file
--------- ----------------
FS$$TOU C:\ti2000\myprojects\Current\ppcPrimary4.06\Out\PCMC_RELEASE_NB\Obj\DSP28_Adc.obj
FS$$MPY C:\ti2000\myprojects\Current\ppcPrimary4.06\Out\PCMC_RELEASE_NB\Obj\DSP28_CpuTimers.obj
UL$$MOD C:\ti2000\myprojects\Current\ppcPrimary4.06\Out\PCMC_RELEASE_NB\Obj\DSP28_CpuTimers.obj
FS$$ADD C:\ti2000\myprojects\Current\ppcPrimary4.06\Out\PCMC_RELEASE_NB\Obj\DSP28_CpuTimers.obj
FS$$TOUL C:\ti2000\myprojects\Current\ppcPrimary4.06\Out\PCMC_RELEASE_NB\Obj\DSP28_CpuTimers.obj
FS$$CMP C:\ti2000\myprojects\Current\ppcPrimary4.06\Out\PCMC_RELEASE_NB\Obj\DSP28_CpuTimers.obj
FS$$DIV C:\ti2000\myprojects\Current\ppcPrimary4.06\Out\PCMC_RELEASE_NB\Obj\DSP28_CpuTimers.obj
L$$TOFS C:\ti2000\myprojects\Current\ppcPrimary4.06\Out\PCMC_RELEASE_NB\Obj\DSP28_Ev.obj
L$$DIV C:\ti2000\myprojects\Current\ppcPrimary4.06\Out\PCMC_RELEASE_NB\Obj\DSP28_Scia.obj
L$$MOD C:\ti2000\myprojects\Current\ppcPrimary4.06\Out\PCMC_RELEASE_NB\Obj\DSP28_Scia.obj
FS$$SUB C:\ti2000\myprojects\Current\ppcPrimary4.06\Out\PCMC_RELEASE_NB\Obj\DSP28_XIntrupt.obj
FS$$TOI C:\ti2000\myprojects\Current\ppcPrimary4.06\Out\PCMC_RELEASE_NB\Obj\PPMC_CommandTerminal.obj
FS$$TOL C:\ti2000\myprojects\Current\ppcPrimary4.06\Out\PCMC_RELEASE_NB\Obj\PPMC_CommandTerminal.obj
U$$DIV C:\ti2000\myprojects\Current\ppcPrimary4.06\Out\PCMC_RELEASE_NB\Obj\PPMC_CommandTerminal.obj
U$$TOFS C:\ti2000\myprojects\Current\ppcPrimary4.06\Out\PCMC_RELEASE_NB\Obj\PPMC_CommandTerminal.obj
U$$MOD C:\ti2000\myprojects\Current\ppcPrimary4.06\Out\PCMC_RELEASE_NB\Obj\PPMC_CommandTerminal.obj
UL$$DIV C:\ti2000\myprojects\Current\ppcPrimary4.06\Out\PCMC_RELEASE_NB\Obj\PPMC_CommandTerminal.obj
I$$TOFS C:\ti2000\myprojects\Current\ppcPrimary4.06\Out\PCMC_RELEASE_NB\Obj\PPMC_CommandTerminal.obj
UL$$TOFS C:\ti2000\myprojects\Current\ppcPrimary4.06\Out\PCMC_RELEASE_NB\Obj\PPMC_CommandTerminal.obj
FS$$NEG C:\ti2000\myprojects\Current\ppcPrimary4.06\Out\PCMC_RELEASE_NB\Obj\PPMC_DataDump.obj
>> error: symbol referencing errors - './Out/PCMC_RELEASE_NB/pcmcFlash.out'
not built
Build Complete,
1 Errors, 3 Warnings, 0 Remarks.
Please view the build output for errors and warnings for any custom steps.
The errors mean that the code is referencing those symbols but cannot find a definition for them. Those symbols are typically defined in the runtime library but for some reason, it looks like it is not finding them in the custom runtime library you are linking with. I think I mentioned ofd2000 in one of my earlier posts. That utility can come in use here as well. Run "ofd2000 -g" on the .lib file and you can confirm which symbols are defined in it, and whether these symbols are there or not.
Thanks for the reminder about ofd2000. Sure enough, when I run that on both lib files, those symbols only show up in rts2800_ml.lib, which explains why it builds clean with that library. If nothing else, I guess this confirms that the rts2812_ml.lib is not used with this project. The run-time problem I am having with the program built with rts2800_ml.lib must be related to something else. I will start looking in another direction. Thanks for your help.
I found a PC with CCS v2 and some of the previous versions of this project I am trying to build. The linker map files generated by that version of CCS show "TMS320C2000 COFF Linker PC Version 3.01" at the top which is exactly the same as the map files from the last known good build of the project I am working on. The PC that has CCS v2, I have to access remotely via the internet and is slow. Any chance of getting a download for CCS v2 now that we have a CCS license so I can install that on my PC locally?
David,
The oldest one I have been able to dig up is CCSv2.12. I can send you a download link for that if you want to give it a try.
Regards,
John
Ok. You should receive a friend request. At the top of the message I will insert the download link
Regards,
John
So I now have CCS v2.12 installed (Good Grief!) and I am getting the following error message:
>> error: symbol _c_int00 is defined multiple times: boot.obj
(C:\ti\myprojects\ppcPrimary4.06\lib\rts2800_ml.lib) and
C:\ti\myprojects\ppcPrimary4.06\Out\PCMC_RELEASE_NB\Obj\boot2812.obj
I realize that this means that _c_int00 is defined in both of the two files specified, but I did not receive this error when I built with CCS v3, v4 or v5. boot2812.obj is the object file created from an assembly source file which I have uploaded as an attachment if this helps. 6237.boot2812.asm. Not really sure what to do at this point.
David Burke1 said:I realize that this means that _c_int00 is defined in both of the two files specified
That is correct. However, if the boot2812.asm source file is part of your project, and appears on the link command line prior to the rts library, then the linker should resolve the reference to the one in boot2812.asm. At least that is how the newer tools work. I honestly cannot say with confidence if the v3.0x worked any differently since it is extremely old and I have no experience working with this version.
I would recommend checking the link command (I believe it should be in the Debug.lkf or Release.lkf file), and make sure that boot2812.obj appears before rts2800_ml.lib. If it does not, there must be some way to control the order but I'm not sure how/where that option appears in CCS 2.12. Sorry that I'm not able to provide more precise answers but these are unfortunately very old tools that haven't been supported in quite some time.
Make sure that boot2812.obj defines at least all the same symbols as rts2800_ml.lib<boot.obj>. If you miss one, the program might still have an unresolved symbol which can only be satisfied by pulling in rts2800_ml.lib<boot.obj>, which will then collide with your _c_int00.
What version of the C2000 compiler are you using in CCS v2.12? It is not the same as the CCS version.
Does anyone know if there is a utility I can use that would read the original (known good) project .out file and tell me exactly what version of the rts2800_ml.lib file was used to built that .out file?
Also, will it make any difference what JTAG module driver I am using when I build this program if I am not planning on doing any debugging? In some of the documentation we have from the previous known good build, they say that they used Spectrum Digital drivers. I just want to know if this would have any affect on how the release version of the program would run.
Ok. The original CCS project did not include rts2800_ml.lib in the project itself. I actually added it manually because I kept getting build errors related to undefined symbols. So I have now removed it from the project (like the original configuration). I started getting the undefined symbol errors again. These symbols are defined in the rts2800_ml.lib. Since this is a standard CCS library, shouldn't it automatically know to look in it's library directories for this? So I went into the project build settings (linker section) and added the Library search path "...\C2000\cgtools\lib" and added rts2800_ml.lib in the "Incl Libraries" field. Doing this then automatically eliminated the reference to rts2800_ml.lib from the release.lkf file. After making these changes, I rebuilt and still get the same error (i.e. symbol _c_int00 is defined multiple times). So relative to your suggestion about making sure boot2812.obj appears before rts2800_ml.lib, if rts2800_ml.lib no longer appears in that file, how do I control what order the linker looks at these two files? For whatever it's worth, when I do the same thing in CCS v3, I get the same results. Also, if I make these exact same changes in CCS v5, it builds clean, but will not run on our system, which I am thinking might be related to the version of the rts2800_ml.lib that is getting used since the last known good build was done with CCS v2 as previously stated.
Frankly, you're making too many changes at once for me to keep track of what's going on. Please try to avoid saying "the same" when describing symptoms; to avoid confusion, please explicitly list the conditions and symptoms for each distinct attempt.
I'm going to try to address the problem with multiple definitions of _c_int00. Please post the linker map file from an instance where you get multiple definitions of _c_int00. Also please indicate the version of the compiler you are using as well as the complete command-line options.
Linker Map File:2804.pcmcFlash_map.txt
Project File with Command Line Options:
; Code Composer Project File, Version 2.0 (do not modify or remove this line) [Project Settings] ProjectName="DSP28" ProjectDir="C:\ti2000\myprojects\Current\ppcPrimary4.06\" ProjectType=Executable CPUFamily=TMS320C28XX Tool="Compiler" Tool="CustomBuilder" Tool="DspBiosBuilder" Tool="Linker" Config="PCMC_RELEASE_NB" [Source Files] Source="lib\rts2812_ml.lib" Source="src\boot2812.asm" Source="src\DSP28_Adc.c" Source="src\DSP28_CpuTimers.c" Source="src\DSP28_DefaultIsr.c" Source="src\DSP28_Ev.c" Source="src\DSP28_GlobalVariableDefs.c" Source="src\DSP28_Gpio.c" Source="src\DSP28_Mcbsp.c" Source="src\DSP28_PieCtrl.c" Source="src\DSP28_PieVect.c" Source="src\DSP28_Scia.c" Source="src\DSP28_Scib.c" Source="src\DSP28_Spi.c" Source="src\DSP28_SysCtrl.c" Source="src\DSP28_Xintf.c" Source="src\DSP28_XIntrupt.c" Source="src\flashstart.asm" Source="src\PPMC_Buzzer.c" Source="src\PPMC_CommandTerminal.c" Source="src\PPMC_Contactor.c" Source="src\PPMC_DataDisplayAPI.c" Source="src\PPMC_DataDump.c" Source="src\PPMC_DPRAM.c" Source="src\PPMC_EEPROM.c" Source="src\PPMC_Faults.c" Source="src\PPMC_FLASH.c" Source="src\PPMC_Init.c" Source="src\PPMC_Main.c" Source="src\PPMC_paramTable.c" Source="src\PPMC_RTC.c" Source="src\PPMC_spiADC.c" Source="src\PPMC_UIB.c" Source="src\PPMC_UserInterface.c" Source="cmd\PPMC.cmd" ["PCMC_RELEASE_NB" Settings] InitialBuildCmd=copy.\cmd\PCMC_TMX320F2812_New_Boot.cmd .\cmd\ppmc.cmd FinalBuildCmd=cd Out\PCMC_RELEASE_NB FinalBuildCmd=hex2000 pcmchexNewBoot.cmd FinalBuildCmd=hex2ppc2 pri__APvCN.hex ["Compiler" Settings: "PCMC_RELEASE_NB"] Options=-g -k -q -ad_DEBUG=0 -ad_RELEASE=1 -as -fr"C:\ti2000\myprojects\Current\ppcPrimary4.06\Out\PCMC_RELEASE_NB\Obj" -fs"C:\ti2000\myprojects\Current\ppcPrimary4.06\Asm" -i"C:\ti2000\myprojects\Current\ppcPrimary4.06\include" -d"LARGE_MODEL" -d"_PCMC_" -u"_PPMC_" -u"_DAC_" -ml -v28 ["Linker" Settings: "PCMC_RELEASE_NB"] Options=-q -c -m".\Out\PCMC_RELEASE_NB\pcmcFlash.map" -o".\Out\PCMC_RELEASE_NB\pcmcFlash.out" -x ["src\boot2812.asm" Settings: "PCMC_RELEASE_NB"] Options="Compiler" +{-d"_RELEASE"}
I don't know how to tell what the version of the CCS v2 compiler is. I can only tell you that it is the same version that was installed by the CCS v2 installer. The specific version of CCS is 2.12.00
The linker map file says "TMS320C2000 COFF Linker PC Version 3.13", so I'm sure the compiler version is the same: C2000 version 3.13
So far, I haven't been able to reproduce the problem or discern why it might be happening. In the meantime, I re-read the thread and now I'm confused about just what it is you're trying to do, and why you're using an old version of CCS. I thought the reason was that you had an old version of rts2812_ml.lib for which you no longer have access to the source code, and which (despite its name) was compiled for C2700, not C2800. However, later you say:
David Burke1 said:I guess this confirms that the rts2812_ml.lib is not used with this project
And earlier, you indicated that you are using TMS320F2812PGFS, which is a C2800 device. So, could you remind me why you're not using the most recent versions of CCS and the C2000 compiler?
My apologies. The linker map file I provided was from the last known good build (from several years ago) which "we think" was done with CCS v2.00.00. The linker map file from the CCS v2.12 (which we are using now) is attached and says "TMS320C2000 COFF Linker PC Version 3.03" at the top as you can see in the attachment. 2438.pcmcFlash_mapCCSv212.txt
Keep in mind that this entire process has been a major learning experience for me given that I had zero experience in embedded programming. That being said, let me try to summarize what we are trying to do and what has happened thus far.
1. In short, we have a CCS project that was initially created 10 years ago and the last known good build was done early 2010.
2. None of the original developers are still with our company
3. We have some minor changes we want to do to the software but before we start making changes we wanted to re-build the existing “known good” source code and make sure we could get the unmodified code to run on our system first.
4. The first thing we did was downloaded and installed CCS v5, imported the original CCS workspace for this project and attempted to rebuild it without making a single change to anything including project settings, etc. This is when I receive the first build error as follows:
error #16008-D: file ".../rts2812_ml.lib<exit.obj>" specifies ISA revision "C2700", which is not compatible with ISA revision "C2800" specified in a previous file or on the command line
5. After some back and forth with TI in this forum, it appeared as though the reason I might be getting this build error was due to changes made to the CCS build tools since the last known good build several years ago, with whatever version of CCS the developers were using at that time. This is how we got started on the path of going back to earlier versions of CCS.
6. During the time we were waiting for our CCS v3 license, one of the things we tried was adding rts2800_ml.lib directly to the CCS project. This file was already in the project folder (i.e. the computer folder not the CCS IDE folder) so we figured maybe this file was needed to build the project. As soon as we added rts2800_ml.lib to the CCS project, it built all the way through. Then we removed rts2812_ml.lib and built it again and it still built without errors, leading us to believe that rts2812_ml.lib was not even needed. When we tried loading and running the output of the build that excluded rts2812_ml.lib, it would not run on our system. We initially thought this due to using a new version of CCS than the previous developers used which kept us on the path of going back to earlier versions of CCS.
7. The first build that we were able to get to boot up on our system was done with CCS v3.3 with both rts2800_ml.lib and rts2812_ml.lib include directly in the CCS project. This still didn’t make any sense to me because rts2800_ml.lib was never included in the original CCS project or referenced anywhere that I could find. So I still to this day don’t know how this project could have been built when the CCS project never referenced that TI run-time library (rts2800_ml.lib). For reference purposes, we never got the error message (error #16008-D: file ".../rts2812_ml.lib<exit.obj>" …) with CCS v3.3, confirming TI’s speculation that earlier versions of CCS ignored this error. Additionally, if we did not include or reference the rts2800_ml.lib, we would get build errors related to approximately 15 undefined symbols which we verified were not in the rts2812_ml.lib file but were in rts2800_ml.lib.
8. So, since we were still having problems with the program running on our system (it kept rebooting), we assumed it must be related to the CCS v3.3 build tools (compiler, linker, libs, etc.) being different from that which was used by the original developers, hence the reason to keep going backwards until we got as close as possible to CCS v2.00.00 which again we believe is the version used in the last known good build.
9. So today, we have CCS v2.12 installed but have not been able to get by the error:
>> error: symbol _c_int00 is defined multiple times: boot.obj (C:\ti\myprojects\ppcPrimary4.06\lib\rts2800_ml.lib) and C:\ti\myprojects\ppcPrimary4.06\Out\PCMC_RELEASE_NB\Obj\boot2812.obj
10. What’s interesting is we get this same build error with CCS v3.3 but only if rts2800_ml.lib is referenced in the project build options under the linker section (Incl. Libraries field). If we don’t reference rts2800_ml.lib in the project build options under the linker section and just include it in the project (i.e. add it so it’s visible in the project folder shown in the CCS IDE) we don’t get that build error. CCS v2.12 produces the build error with either of these two setups.
So as a quick summary, I can successfully build (i.e. no build errors) with either CCS v3.3 or CCS v5, but in order to do so, I have to add rts2800_ml.lib directly to the CCS project, in addition to the rts2812_ml.lib file that was already in the project. I am confused about this because rts2800_ml.lib was never there to begin with or referenced anywhere I can find, but it appears to be needed. As previously stated, there are many symbols in rts2800_ml.lib that are not in rts2812_ml.lib. If indeed the last known good build did actually use rts2800_ml.lib (which it seems like it must have), it would be nice to know what version they used in their build. Is there any way of determining this using any of the tools that come with CCS?
David Burke1 said:6. [..] When we tried loading and running the output of the build that excluded rts2812_ml.lib, it would not run on our system. [..]
Why not? What error did you get?
Is the original device the same as your current device (TMS320F2812PGFS) ?
David Burke1 said:As previously stated, there are many symbols in rts2800_ml.lib that are not in rts2812_ml.lib. If indeed the last known good build did actually use rts2800_ml.lib (which it seems like it must have), it would be nice to know what version they used in their build. Is there any way of determining this using any of the tools that come with CCS?
There is no direct way to do so. That information is encoded in object files, but it is discarded when creating the executable file. About the only thing you could do would be to compare the disassembly of the executable file to the disassembly of each version of each object file.
The answer to your first two questions:
You say you have the "original (known good) project .out file". Are you absolutely sure this executable (.out) file works properly?
In an earlier post, you say:
David Burke1 said:I found a PC with CCS v2 and some of the previous versions of this project I am trying to build. The linker map files generated by that version of CCS show "TMS320C2000 COFF Linker PC Version 3.01" at the top which is exactly the same as the map files from the last known good build of the project I am working on. The PC that has CCS v2, I have to access remotely via the internet and is slow. Any chance of getting a download for CCS v2 now that we have a CCS license so I can install that on my PC locally?
Can you build an executable file with that installation which works correctly?
Later, you say:
David Burke1 said:So I now have CCS v2.12 installed (Good Grief!) and I am getting the following error message:>> error: symbol _c_int00 is defined multiple times: boot.obj
(C:\ti\myprojects\ppcPrimary4.06\lib\rts2800_ml.lib) and
C:\ti\myprojects\ppcPrimary4.06\Out\PCMC_RELEASE_NB\Obj\boot2812.obj
There should be almost no difference between these two CCS installations. Are you sure the CCS project is identical on these two installations?