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.

CODECOMPOSER: Projectspec Files and COM_TI_SIMPLELINK_* SDK Selection

Part Number: CODECOMPOSER
Other Parts Discussed in Thread: CC2652R, SYSCONFIG

I'm working with a customer that is creating and using their own *.projectspec files, to generate CCS projects for the CC2652R, which uses the TI SimpleLink SDK for CC13x2_26x2. What we are finding is that when the projectspec is uses with the CCS Import tools, CCS always sets COM_TI_SIMPLELINK_CC13X2_26X2_SDK_INSTALL_DIR to point to the "latest" version installed under C:/ti and picked up by CCS. However, both the customer, as well as myself supporting the customer, need to have multiple versions of the SDK installed in CCS to support multiple projects of development on different versions.

How can we force a projectspec to use a specific SDK version for the COM_TI_SIMPLELINK_* variable during the import project? If we perform the import occurs from a SimpleLink SDK example tree itself, it seems to always choose the parent SDK version correctly, not the "latest". However, I cannot seem to discover the mechanism by which this happens. It seems like "magic" is occurring.

The customer needs to be able to maintain the custom pojectspec files outside the SDK tree. It is not an acceptable solution to pollute the SDK sources with custom and/or modified files and code.

Thanks,

Stuart

  • Hello Stuart, 

    I am sending your thread to the bluetooth team. Please ping the thread if they do not respond within a business day or two.

    Regards,

    Nick

  • How can we force a projectspec to use a specific SDK version for the COM_TI_SIMPLELINK_* variable during the import project? If we perform the import occurs from a SimpleLink SDK example tree itself, it seems to always choose the parent SDK version correctly, not the "latest". However, I cannot seem to discover the mechanism by which this happens. It seems like "magic" is occurring.

    Yes I observed the same behavior. I have SDK versions 5.10, 4.40, 4.10. When I import an example 4.40 projectspec from inside the 4.40 SDK directory, The SDK version is specified to be 4.40 in the project. When I copy the SAME projectspec and place it outside the SDK directory and import it, the SDK version will default to the latest available version (5.10 in my case). Hence there is not anything inside the .projectspec itself that explicitly dictates the SDK version. I suspect that CCS determines it based on the fact that the projectspec is being imported from inside a directory for a discovered product of a specific version. If the projectspec is outside of a discovered directory, then it default to the latest version.

    I also took that same projectspec and copied it in some random directory inside my 4.10 SDK install. When I import the projectspec again, the project is configured for SDK 4.10.

    I will try to confirm my findings and see if there is a way to explicitly set this in the .projectspec

    ki

  • Ok it is somewhat documented in the section below:

    https://software-dl.ti.com/ccs/esd/documents/ccs_projectspecs.html#details

    What I did was add the below in bold and red to specify version 4.40.04.04

    <?xml version="1.0" encoding="UTF-8"?>
    <projectSpec>
    <applicability>
    <when>
    <context
    deviceFamily="ARM"
    deviceId="Cortex M.CC1352R1F3"
    />
    </when>
    </applicability>

    <project
    title="GPIO Interrupt"
    name="gpiointerrupt_CC1352R1_LAUNCHXL_nortos_ccs"
    configurations="Debug"
    toolChain="TI"
    connection="TIXDS110_Connection.xml"
    device="Cortex M.CC1352R1F3"
    ignoreDefaultDeviceSettings="true"
    ignoreDefaultCCSSettings="true"
    products="com.ti.SIMPLELINK_CC13X2_26X2_SDK:4.40.04.04;sysconfig"
    compilerBuildOptions="
    -I${PROJECT_ROOT}
    -I${PROJECT_ROOT}/${ConfigName}
    -DDeviceFamily_CC13X2

    ...

    That worked for me.

    Thanks

    ki

  • Ki,

    I tested this and it works brilliantly. Thank you!

    Stuart