CCS/CCSTUDIO3: CCS3.3 in Windows 10

I vote for virtual machine too. If you might be having troubles to get WinXP image, consider XP mode. There are howto's on Internet, how to run XP Mode in virtualbox or alike.

Would a windows 10 32 bit machine support/run CCS3.3?

Kevin Eschhofen said:

Would a windows 10 32 bit machine support/run CCS3.3?

I believe a 32-bit version would help. It should alleviate some of the registry incompatibility issues. However, that environment is even less common than CCSv3.3 on a Windows 10-64 environment (I am not aware of a single instance of that environment yet) so I don't have any idea how it would work (though I do suspect it will be better)

ki

I got a Virtual machine setup with windows XP to support CCS3.3. However, I still get the same link error mentioned above. My confidence is high the VM and XP environment is good (I was able to build a separate project successfully). But I am still getting the link error on the project in question...[ “can not open config.obj for input” with nothing else.]. Is there a case where the linker puts out this message with no secondary detail information? Again this is a 2407a and trying to build under tools 7.04. There is no TI bios for this project.

Other ideas?

Thanks

Kevin

Would it be possible provide a small reproducible test case? I would need the *.pjt and source files to build. Contact me via private message if you wish to share privately

Attached is picture of the link error.

Status refresher: I am in the VM environment under XP. I was abled to build a separate project (2812) in CCS3.3 successfully. So I have confidence in the environment.

However, I am still getting the same error. At this point I am starting to think it is the CCS3.3 or the build tools that is having the problem. Note I removed the config.c file from the project and performed a clean and build. I am getting the same link error indicating it can not find the config.obj file for input, even though the file is not in the projects and does not appear in the debug.lkf file. I should be getting a whole bunch of other link errors due to the absence of the config.c file from build and link (debug.lkf).
We found the latest version of CCS v3.3 (version 3.3.83). I removed the prevsious CCS3.3 (version 3.3.38) and installed the newer one. The interesting thing about this is that the C2400 build tools where mostly missing (CCStudio_v3.3->c2400->cgtools). I copied of the files needed from the previous version install. I then built the project again and got the same link error as the attached picture.
Another question: I understand CCS v3.3 is the last CCS to support the 24xx parts? Is this true?
Another question: With CCS3.3, the build tools for the C2400 are version 7.04. Is there a newer or older version of build tools available? Are there any known issues with 7.04?

You mentioned PMing in the future. I am not seeing where/how that can be done.

Thanks Kevin.

Kevin Eschhofen said:

We found the latest version of CCS v3.3 (version 3.3.83). I removed the prevsious CCS3.3 (version 3.3.38) and installed the newer one. The interesting thing about this is that the C2400 build tools where mostly missing (CCStudio_v3.3->c2400->cgtools). I copied of the files needed from the previous version install. I then built the project again and got the same link error as the attached picture.

What is the full build number of CCSv3.3? Not all CCSv3.3 install packages have 24x build support. Do you have the special version designed for 24x support? For example, the latest CCSv3.3 version does NOT have 24x support (3.3.83.20)

Kevin Eschhofen said:

Another question: I understand CCS v3.3 is the last CCS to support the 24xx parts? Is this true?

Yes. But as noted above, not all CCSv3.3 versions support 24x.

Kevin Eschhofen said:

Another question: With CCS3.3, the build tools for the C2400 are version 7.04. Is there a newer or older version of build tools available? Are there any known issues with 7.04?

7.04 is the latest version. Check the release notes in <CCSv3.3 INSTALL DIR>\C2400\c2400_cgt.txt for more details on that version.

Thanks

ki

Hi Ki,

I have the problem fixed mentioned above, which was a reference to the file config.c in the link.cmd file. I had to put the entire path to the file to resolve the link error in link.cmd file.
I am not sure why the entire path is needed!?

I have progressed on to another issue. This code I am building has a ".vectors" section. This is conflicting with the "vectors" section in the RTS (rts.src). I get the link error "cannot allocate vectors in VECTORS". It looks like the linker put my ".vectors" in the *.map file and is also trying to fit "vectors" (from the RTS) into the same section, but it will not fit. How can I make my ".vectors" replace or override what is in the RTS library

Kevin Eschhofen said:

I have the problem fixed mentioned above, which was a reference to the file config.c in the link.cmd file. I had to put the entire path to the file to resolve the link error in link.cmd file.
I am not sure why the entire path is needed!?

How was the file referenced?

Kevin Eschhofen said:

I have progressed on to another issue. This code I am building has a ".vectors" section. This is conflicting with the "vectors" section in the RTS (rts.src). I get the link error "cannot allocate vectors in VECTORS". It looks like the linker put my ".vectors" in the *.map file and is also trying to fit "vectors" (from the RTS) into the same section, but it will not fit. How can I make my ".vectors" replace or override what is in the RTS library

This is a question best served by the compiler experts. Please start a new thread for this question.

Thanks

ki

The link command file was included under the CCS3.3 project. Within the link command the config.obj is being reference to location certain sections to specific areas. See below:

        .task   :
     {
                   config.obj(.bss)                  /* These files .bss sections    */
                   event.obj(.bss)                   /* added here so temp vars are  */
                                                              /* visible during NOVRAM ops!   */
    } > TASK_STK  PAGE 1  /* task stacks                  */

It is complaining it can find config.obj in this reference. I had to add the entire path.

        .task   :
     {
                   w:\software\dev\ControlBoard\debug\config.obj(.bss)                  /* These files .bss sections    */
                   w:\software\dev\ControlBoard\debug\event.obj(.bss)                   /* added here so temp vars are  */
                                                                                                                         /* visible during NOVRAM ops!   */
    } > TASK_STK  PAGE 1  /* task stacks                  */

Not sure why the entire path is needed.

Assuming that the .cmd file is in  w:\software\dev\ControlBoard\ and "debug" is the configuration subfolder, try:

.task   :
{
    .\debug\config.obj(.bss)                  /* These files .bss sections    */
    .\debug\event.obj(.bss)                   /* added here so temp vars are  */
                                              /* visible during NOVRAM ops!   */
} > TASK_STK  PAGE 1  /* task stacks                  */

I tryed this and I get an error saying multiply defined .\debug\Config.obj and w:\software\dev\ControlBoard\debug\Config.obj. If I have the complete path the errors go away.

I see. Sounds like a limitation of where the linker cannot resolve that both object files are the same.