How to force a CCS Project import that actually copies ALL files to the workspace?

Hi Mike,

you can certainly get rid of relative paths (ie create an absolute path) in your linked files.  You can also manually add and copy in to your project all necessary files.

Let me dig a bit more to see what other options might be available for you.  What many do is create their own project/code and use the unmodified libraries from Stellarisware for example.

This wiki might be of interest as well.

http://processors.wiki.ti.com/index.php/Include_paths_and_options

Best Regards,

Lisa

Hi Mike,

I have been able to confirm for you that unfortunately, you can not modify whether a resource is linked or not after the fact.   The only option is to manually copy in files you do not wished as linked resources.

Hope this helps explain and sorry for any inconvenience.

Best Regards,
LIsa

Lisa,

The other thing I think I noticed that should be documented somewhere is that doing a copy paste in the project window creates the new project, but it doesn't make a copy of the project.  It creates a new project folder, but it also provides links instead of copies.  This could be disastrous for someone creating a new project based on an old one, and then having the source files in the original changed via links.

Sincerely,

Mike fontes

Mike,

Please see these sections of the wiki article:

http://processors.wiki.ti.com/index.php/Projects_and_Build_Handbook_for_CCS#Importing_projects
http://processors.wiki.ti.com/index.php/Projects_and_Build_Handbook_for_CCS#Copying_Projects

Lisa,

I don't think the importing projects works like it says based on my attempt this morning.  I created a new workspace and imported the V200 of the mcbsp_loopback_dma_c28 project into the new workspace using the copy to workspace checkbox.  I browsed to the project in the coutrolsuite directories to point to it.  When my import was complete all the .c files were linked to the original Controlsuite directories, and there were no .c files in the directory tree in my workspace.  That is how I confirmed the issue.  I have not destroyed anything yet so I could send window snapshots showing this if you need it.

The import files wiki page states ""copy to workspace" checkbox means that everything in the project folder will be copied to the workspace, that means the project files and any source files that are present within the project folder".  When I did it the source files in the controlsuite directories were not copied.  Instead links to those files were created.

Sincerely,

Mike Fontes

Hi Mike,

let me see if I can look at this in a bit more detail for you and reproduce things here.  What exact ccs version are you using?  Do you also know the control suite version?

Best Regards,
Lisa

Lisa,

I have CCS 5.3.0.000090 and the CONTROLSuite that just got pushed a few days ago.  The project I tried to copy in was the v200 mcbsp_llopback_dma from the M36 Control Examples directory.  Since I haven't been notified I think everything is at its latest version. Pleae let me know if there is anything else you need me to send.  I will keep the created directories intact and use a different workspace so I can collect any screen shots you need me to send.

Sincerely,

Mike Fontes

Mike Fontes said:

When my import was complete all the .c files were linked to the original Controlsuite directories, and there were no .c files in the directory tree in my workspace. 

Based on how the original project is set up in ControlSuite there are no source files within the project folder (which in this case is C:\ti\controlSUITE\device_support\f28m36x\v110\F28M36x_examples_Control\mcbsp_loopback_dma\c28\ccs or similar). Note how the CCS project files (.project, .cproject etc) are inside that folder but one of the C source files is one level up and all the other C source files are dispersed in other folders within ControlSuite.

Mike Fontes said:

The import files wiki page states ""copy to workspace" checkbox means that everything in the project folder will be copied to the workspace, that means the project files and any source files that are present within the project folder".

The "project folder" is the folder that contains the project files(.project, .cproject etc) so only the resources inside that folder will be copied over. In these examples, since none of the C source files are within the project folder, none of them are copied over.

Does this help explain?

Aarti,

It helps explain the issue.  I know now thaat the only way to be safe is going to be to create things manually when using the examples since there is too much of a level of indirection, that is not easily seen by the user like me when attempting to import the existing projects.  I can only get that info by doing a bunch of research before the import occurs.

With that in mind how do I successfully bring in all the source files to a new project based on the examples?  I am not sure how to ensure I am getting everything I need.  Is there an example showing the creation of a project that way, and how to find the different files required to get a working, debuggable project?  In other words, if I want to create a complete mcbsp_loopback_dma project from scratch, with all the necessary files in it, and no links?

Sincerely,

Mike Fontes

Mike Fontes said:

With that in mind how do I successfully bring in all the source files to a new project based on the examples?  I am not sure how to ensure I am getting everything I need.

The only way to ensure you are getting everything you need is to import and inspect one of the example projects. You can see which source files are required by looking at the Project Explorer view. In addition, you would need to check which linker command files and libraries are required. This may or may not be visible in the Project Explorer view (depending on how the original project was set up). The other place to check them is under Project Properties->Build->Linker->File Search Path. Any additional linker command files and libraries should be listed there.

You can then make a copy of an example project, delete all the linked references, and copy all the required resources from their original ControlSuite location over to your project folder. Note that some of the source files will include header files which would still reside in ControlSuite, so you need to ensure that the appropriate include paths are set up to point to those correctly. Since there a quite a few levels of dependency to common source files and header files within ControlSuite, the project copy process is not as simple and straightforward.

Please also see this wiki that suggests some options for copying example projects:
http://processors.wiki.ti.com/index.php/Creating_copy_of_example_project

Aarti,

I have been working to create a workspace project that uses only source code from the workspace project directory.  Since I had been working with the McBSP DmA Loopback I decided to use that project as my base.  I created a new workspace, and started to bring in the files thaat were in the example to my project directory.  Since the latest version 200 of the Controlsuite came down last week I decided to use that as my base, and prepared to make the changes I needed.  I have run into 2 issues. They are:

1. It seems there has been a change in the F28M36x_Gpio.h file between the V110 and V200 that is affecting the code I am using.  In the definition for the struct GPIOG1_CTRL_REGS the definitions for GPIOs 96 - 127 have been removed from the v200 file.  That is a problem for those of using the GPIO96 for McBSP Read clk.  Is there a reason for this change?  Are those GPIO not going to be supported?

2. If I choose to temporarily ignore the problem above and define a clk from the other available choices I run into a problem with the cmd file when linking.  It says there are Section errors, although I see the section statements in the cmd file.  I am not sure how to create a new file so I brought in one from the default project creation into my project. The linker now uses both, and creates an out file.  There are two different cmd files used by the linker to create the out.  How do I figure out what was actually created for the memory dump?  Is it in the map file?  How do I combine what I need from the two to create a single, correct cmd file?

Sincerely,

Mike Fontes

Mike Fontes said:

It seems there has been a change in the F28M36x_Gpio.h file between the V110 and V200 that is affecting the code I am using.  In the definition for the struct GPIOG1_CTRL_REGS the definitions for GPIOs 96 - 127 have been removed from the v200 file.  That is a problem for those of using the GPIO96 for McBSP Read clk.  Is there a reason for this change?  Are those GPIO not going to be supported?

It would be best to pose this question to the C2000 device forum as the controlSuite code comes from that team and the experts there should be able to answer this.

Mike Fontes said:

If I choose to temporarily ignore the problem above and define a clk from the other available choices I run into a problem with the cmd file when linking.  It says there are Section errors, although I see the section statements in the cmd file.  I am not sure how to create a new file so I brought in one from the default project creation into my project. The linker now uses both, and creates an out file.  There are two different cmd files used by the linker to create the out.  How do I figure out what was actually created for the memory dump?  Is it in the map file?  How do I combine what I need from the two to create a single, correct cmd file?

The ControlSuite example links in F28M36x_generic_C28_RAM.cmd from ${INSTALLROOT_F28M36X_V200}/F28M36x_common/cmd/ and F28M36_Headers_nonBIOS.cmd. Are you saying that you are adding another linker command file into the project? I would suggest sticking with these default ones and modifying them as needed. As far as what is in the linked output, yes the link map file is the best place to look.

Aarti,

I'm sorry for the delay in the answer to this question.  At your suggestion I have been working on manually creating the project I want to run based on the McBSP loopback project.  Since I decided to use the latest version of the ControlSuite projects I ran into a problem with the updated libs having some missing definitions and changes. I worked with Trey German on those over the past couple of days via another posted conversation.  I am now back to the original problem, with an unexpected twist.

Per my past postings I told you that my project was using two cmd files to do its linking.  It actually was, but I can no longer show it because one of the files has been blown away from my computer.  In my due diligence I was trying to try a build with each of the three combinations so I could report all the results in this post.  I decided to remove one of the cmd files from the project and them rebuild.  When I chose to remove the file from the project I got a window asking me to confirm that I wanted the cmd file to be removed from the file system.  I said yes. BAD CHOICE! It doesn;t just remove it from theproject, it totally removes it from the computer! The file isn't in the Recycle bin, and two different recovery programs could not even find its traces on the hard drive!

With that problem I no longer have two cmd files to look at.  I am back to the original Non-BIOS cmd file that comes with the project and the libs.  I am still having failures related to linker memory setup so I am going to send you a ZIp with the project in it.  Keep in mind that other than library files I don't plan on changing, every file in the project is now located locally in my workspace directory for the project.  Included are some files you would expect in the ControlSuite directories, mainly because my project will be using them with minor changes related to hardware setups, and I don't want to overwrite the distribution files so I am breaking those links.

At this point the project compiles, but it fails in the linking process because it doesn't know where to put several items in memory.  I have looked at the messages and I honestly don't know what to change because the cmd file I am using now exactly matches the one that comes with the project, but I am getting errors I don't get with the distributed project.  Can you take my project and see if you can help me determine how to solve these memory issues?

Sincerely,

Mike Fontes

6837.Cap_Sensor_1_C28.zip

Aarti,

I am working with the SECTIONS directive trying to tell the linker where to put the problem data.  I have been able to remove the cinit, bss, etc. except for the .text area because it is too large to randomly throw into the Page 1 area.  I can see in the manual how to define memory areas so I could possibly solve the issue.  I have a problem because I don't know how the memory in the F28M36 chip is allocated.  I can see the sizes of all the sections on the chip, but I have not been able to find a memory map actually showing where in memory space each of the blocks resides.  Is there a map or table showing me how to determine the final locations of specific memory blocks so I can update my .cmd file with the specifics I need?

Sincerely,

Mike Fontes

Mike,

I wasn't able to build your attached project. I ended up with compiler errors likely because I am missing your include files (which it appears that you have modified from the ones in ControlSuite).

The errors I see are of this nature:

"../F28M36x_Gpio.c", line 33: error #137: struct "GPIOG1_CTRL_REGS" has no field "GPCMUX2"

"../F28M36x_Gpio.c", line 34: error #137: struct "GPIOG1_CTRL_REGS" has no field "GPDMUX1"

"../F28M36x_Gpio.c", line 35: error #137: struct "GPIOG1_CTRL_REGS" has no field "GPDMUX2"

 In any case, I suspect the linker errors you are seeing are due to a missing linker command file. If you take a look at the mcbsp_loopback example in ControlSuite, you can see that the BIOS headers cmd file is linked to the project, but there is also other cmd file that is passed to the linker. If you go to Project Properties->Build->Linker->File Search Path, you will see under --library option that the F28M36x_generic_C28_FLASH.cmd is being passed to the linker. It is this file that defines the memory map and section allocation for the device. 

I would suggest adding this file F28M36x_generic_C28_FLASH.cmd to your project and if needed edit it per your requirements.

As regards to memory map for the F28M36, that is documented in the datasheet: http://www.ti.com/lit/sprs825. But rather that creating your linker command file from scratch by looking at the memory map, I would strongly recommend starting with the one above from ControlSuite.

Aarti,

The addition of the F28M36x_generic_C28_FLASH.cmd file fixed the problem. Thanks for your help.

Sincerely,

Mike Fontes