MSP432E411Y-BGAEVM: Committing CCS projects to version control

Hi Jim,

Jim Whitehouse said:

the TI RTOS project and the modified SDK have been placed in a "lib" directory within the main project directory. This now fails to build with the command line pipeline.

Did you update the compiler include path and the search path for the linker for the library?

Jim Whitehouse said:

I simply add the TI_RTOS project to my workspace and it is fine, but I can't see any modified files, reflecting that change, that I might commit back to fix the pipeline build. It seems that the linked resource location is a feature of the workspace rather than the project, but the project sits inside the workspace location (potentially one of several projects) so the workspace is not currently part of the repository. Does the workspace need to be committed? If so, I still can't spot any workspace files that give the linked resource location.

I think I'm not so clear here. What is the TI_RTOS project here? What modified files are you talking about? Is it the files you modified for the TI_RTOS project or the main project? What files you modified are not reflected? I must admit that I'm not an expert in the SimpleLink and TI-RTOS inner working. Some of the files for SDK are generated based on the .syscfg for SL SDK and .cfg for TI-RTOS. I'm not sure which files you modified. I know that files such as ti_drivers_config.c and ti_drivers_config.h are generated based on the .syscfg. If you modify these files then the next time they will be overwritten when you rebuild the project. 

Using uartecho.syscfg as an example, you can expand the generated files and exclude them from being generated again if you happen to modify these files. 

Hi Charles,

Thanks for having a look.

First, to be clear, I am not having a problem building my project, I can do that. My problem is committing it to VC so that others can build it.

Regarding the TI_RTOS project:

When you first import a TI RTOS based example (e.g. tcpecho_MSP_EXP432E401Y_tirtos_ccs) you also get a second project in your workspace - tirtos_builds_MSP_EXP432E401Y_release_ccs. This TI_RTOS project contains release.cfg where you can make configuration changes to the RTOS (number of priorities, vector location, enable task labels...). It build an RTOS lib sysbios.aem4f.

The main project has "tirtos_builds_MSP_EXP432E401Y_release_ccs" as a linked resource, and inherits some important symbols from it, such as the SDK location and some other paths.

We have moved the TI RTOS project into a lib directory within the main project. As long as the workspace is updated to include the TI RTOS project from its new location, it all builds.

We have also moved the SDK into the lib directory inside the main project directory. I set the new location of the SDK in the TI_RTOS project - everything builds OK. (To do this step, I added the new instance of the SDK to CCS under its preferences settings - it is then possible to add the new SDK to the RTOS project in its properties dialog)

The problem is that for both of these changes I can't see any file that has changed to reflect the new locations. There seems to be no changed files that I can commit to update these new locations. My build works, but the build server fails.

Jim

Hi Jim,

  I don't know how to answer your question. I need to forward your question to our CCS experts for comments on how/if the projects are registered in the workspace metadata.

  This is what I can see. In tcpecho_MSP_EXP432E401Y_tirtos_ccs there is the dependencies for tirtos_builds_MSP_EXP432E401Y_release_ccs. 

In the linker library search path, there is the below path to tirtos_builds_MSP_EXP432E401Y_release_ccs. 

I suppose your question is after you move tirtos_builds_MSP_EXP432E401Y_release_ccs to a sub-directory such as /lib in the main project, you want to know which metadata file is changed among the various workspace metafiles so that you can put that metadata under version control. Is this the correct understanding?

I will move your post to our CCS experts for comment. In the meantime, I think there is an experiment you can do. Create another workspace that has your main project and tirtos_builds_MSP_EXP432E401Y_release_ccs in parallel hierarchy as the same as the example tcpecho_MSP_EXP432E401Y_tirtos_ccs. Do a Beyond Compare between the two workspaces for workspace and ccs metafiles. The other workspace being the one that you move tirtos_builds_MSP_EXP432E401Y_release_ccs  to /lib under the main project. I don't know if this compare will reveal anything as to the location change for tirtos_builds_MSP_EXP432E401Y_release_ccs. 

Hi Jim,

Jim Whitehouse said:

We have moved the TI RTOS project into a lib directory within the main project.

Did you consolidate the TI-RTOS project into the main project so that you are working with just one RTSC project? Or are they two separate projects with the dependent RTOS project folder simply physically moved to the lib directory of the main project?

Jim Whitehouse said:

It seems that the linked resource location is a feature of the workspace rather than the project

Both linked resource path variables and build variables can be set at both workspace and project level. If set at the workspace level, then that information would be stored in the workspace folder metadata. See the "variables" section of the below document:

https://dev.ti.com/tirex/explore/node?node=A__APCOPn6qUQAjzKNUeB0cuQ__ccs_devtools__FUz-xrs__LATEST

Jim Whitehouse said:

Second, the main project is importing the SDK location via the TI_RTOS project. This was pointing to an old version on my hard drive so naturally will not work on the build server.

Information for discovered products is actually per CCS installation. Once CCS "discovers" a product (like an SDK or TI-RTOS), that information is stored in a file inside the CCS directory and would apply to all workspaces using that same CCS installation. If a new CCS installation is being used, then the product would need to be rediscovered by that CCS installation.

See "Product Discovery" in the below article: https://dev.ti.com/tirex/explore/node?node=A__AO8DVCZhl0Kt5-yIAVmyvQ__ccs_devtools__FUz-xrs__LATEST

Hope this helps clear some things up.

ki

Hi,

Thanks for the help.

I have not consolidated the RTOS project into my main project - that might help. Is there any info available on how to do that?

Our build server experts have managed to make it build by moving the RTOS project into the same top level directory as the main project - this directory is passed to the Eclipse command line build tool as the "workspace" then it finds the linked resource.

The other trick they required was to install the SDK in Code Composer on the build server. Unfortunately, this means that anyone cloning the repository must  also do this before they can build - it isn't all self contained in the repository. I suppose that is no different to requiring that the compiler is installed, but I'd assumed the project would know about it!

The final trick is renaming the SDK. We have several boards using the MSP432E401 and ...411 and these require different mods to the SDK so we need to install several different versions which need different names. It seems we can do this by tweaking a few of the manifest files in the SDK.

Thanks

Jim

Jim Whitehouse said:

I have not consolidated the RTOS project into my main project - that might help. Is there any info available on how to do that?

It would involve converting your main project to a RTSC project and adding the appropriate files. This is a bit beyond my area of expertise and I'm not sure this is something you want to try.

Jim Whitehouse said:

Our build server experts have managed to make it build by moving the RTOS project into the same top level directory as the main project - this directory is passed to the Eclipse command line build tool as the "workspace" then it finds the linked resource.

Since the RTOS project is a dependent project of the main project, they would both need to be imported into the workspace 

Jim Whitehouse said:

The other trick they required was to install the SDK in Code Composer on the build server. Unfortunately, this means that anyone cloning the repository must  also do this before they can build - it isn't all self contained in the repository. I suppose that is no different to requiring that the compiler is installed, but I'd assumed the project would know about it!

Are they installing the SDK inside CCS so that it is auto-discovered? You typically do not want to install the SDK inside the CCS folder.