CODECOMPOSER: XDC Dependency Question

Bert

Part Number: CODECOMPOSER
Other Parts Discussed in Thread: AWR6843,

Precursor
This is somewhat related to my other post on the Sensor Forum with regard to building my AWR6843 based project on a headless Jenkins server.

However, there's one area that I can't seem to wrap my head around, and that's the use of XDCTools, and actually XDC as a whole.

This is 100% a misunderstanding on my end, so bear with me while I try to explain.

Overview
Imagine you have a project built to support one of TI's mmWave sensors. In general you would have some custom source files, precompiled mmWave libraries, and an RTOS of choice, in this case SYS/BIOS.

I'm glossing over the details, but at a high level, you have now linked against the two main components, one being the mmWave SDK, and the other being SYS/BIOS.

By default, the installation path for these components would be under C:\ti. For example, if installing the mmWave SDK it would install to C:\ti\mmwave_sdk_03_05_00_04, and the same applies for BIOS C:\ti\bios_6_73_01_01.

From a project portability standpoint, it may make sense to wrap those components up into something like a git submodule, or maybe zip them up and store in Artifactory. Basically a way to internally host that particular read-only package.

The point being, each and every developer who works on the project would not have to worry about installing the mmWave SDK, or the RTOS for that matter, as it would be packaged along with the projects source code.

For example, the project structure could look something like this:

C:\git_ws\ProjForE2ePost
├───Build
│       YourEnvBatchFilesHere.txt
│       YourMakeFilesHere.txt
│
├───DSS
│       YourDspCcsProjHere.txt
│
├───MSS
│       YourMcuCcsProjHere.txt
│
├───SW
│       YourCoreSwHere.txt
│
└───TI
    ├───bios_6_73_01_01
    ├───dsplib_c64Px_3_4_0_0
    ├───dsplib_c674x_3_4_0_0
    ├───mathlib_c674x_3_1_2_1
    ├───mmwave_sdk_03_05_00_04
    ├───xdctools_3_50_08_24_core
    └───xdctools_3_62_00_08_core

Yes, there is a trade off here, as the dev would then have to sit and wait for all those packages to be pulled down into their branch, but it's one that we can work around.

For this scenario, in theory, a headless Jenkins system could then pull this project down, and build it, without having Code Composer installed. It has the makefiles, and all of the project dependencies, so it should be able to compile and produce the resulting build artifacts.

Well, that's where I went wrong. The build fails, as it's looking for XDCTools, a 64-bit JVM, and a specific version of gmake, which is found in C:\ti\ccs1100\ccs\utils\bin

Question
What I can't seem to find out is, where is it pulling those XDC paths from? And what is XDC being pulled in for? If I look in the .cproject, or .ccsproject, I don't see a specific path. In fact, I don't see any paths that contain c:\ti, So XDC must be pulled from somewhere else.

Before I dig too much deeper, I wanted to at least see if any of my thoughts above make sense, or if I'm off in the weeds :).

Thanks!

over 4 years ago

+1 Bert over 4 years ago

Prodigy 130 points

Alright, I made some progress since my last post. I'll fumble through an explanation, with the hopes that it may help someone else down the road.

In terms of XDC and RTSC, I still don't fully get the big picture, but will poke around at the TI training series to see of anything pops up.

That said, in terms of the XDCTools path issue I mentioned above, it had to to with a version discrepancy.

I'll explain, and maybe someone from TI can confirm the theory.

There's many existing posts on e2e which discuss the XDC_CG_ROOT environment variable. This particular variable is read-only, and from what I can tell, is only set based on 'Product Discovery Paths'.

Within that dialog, there's your standard hard-coded paths for C:\ti, C:\ti\ccs1100, and C:\Program Files\Texas Instruments.

Optionally, you can add your own path for the modules of interest. In my case, that's the first thing I did, but no matter what I tried, the path provided was never able to detect any additional XDCTool modules.

A couple hours into the debug session I decided to 'uninstall' all versions of XDCTools. I then unselected the standard TI discovery paths, and selected only my custom path. By doing that, it was able to find *almost all of the desired modules, and in turn the XDC_CG_ROOT variable was set as expected.

When looking at versions, my XDCTools version (3.50.08.24) was the same one living under C:\ti\xdctools_3_50_08_24_core. As a result, when I originally started this thread I had C:\ti selected as a search path, as well as my custom search path, and therefore it must have trumped my version, which prevented it from being detected?

I still don't understand that part. The red arrow above shows that xdctools_3_50_08_24_core exists, and lives in the specific search path, but for whatever reason CCS detects the other version, but not xdctools_3_50_08_24_core.

Based on my version of SYS/BIOS (6.73.01.01), the notes explicitly mention XDCTools 3.50.08.24 as the recommended version, so it bugs me a little that I can't install it, but I'm at least unblocked now, and will use 3.62.0.8 in the meantime.

In terms of the 'portability' portion of the original post, once my discovery paths were set, the next step was to do the same discovery process, but for the compiler. i.e instead of reaching into C:\ti\ti-cgt-arm_16.9.6.LTS, I had it point to my custom path. The same applied to the DSP compiler.

At that point, the only thing (that I know of) that I was dependent on was the underlying utilities that CCS uses to build, i.e gmake, which is linked to an environment variable CCS_UTILS_DIR.

Now that those paths are all resolved and pointing to a custom path, I am going to move the project over to a machine without CodeComposer and see if it builds.

Code Composer Studio™︎

Code Composer Studio forum

CODECOMPOSER: XDC Dependency Question