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.

syscfg and non-syscfg configurations in one CCS project

Other Parts Discussed in Thread: SYSCONFIG, CCSTUDIO

Hi TI,

As you might be aware, the MSP432P401R backing has been showing some unpredictable behavior. (device silently disappearing, supporting software no longer present on TI website, no longer selectable as part number in support forum etc etc). We had designed and programmed a product based on this micro and are not that happy about this all. As a consequence, we are looking for other controllers to perform the same role.

To reuse as much of the code base (and keep a functional build configuration for the origional msp432p401) i would like to add a new build configuration to the same CCS project. I add a new configuration, where the wizard only allow me to copy from an existing configuration. In the new configuration, in the project properties -> CCS general -> Project page: the device family and variant shows greyed out. A small info notification points to the sysconfig for changing the device variant.

How can i add a new configuration with a different device family and variant, quite possibly not using sysconfig to the project?

Thanks in advance for your time.

  • Hello,

    I know it is possible to switch devices in the sysconfig editor, and I know you can have more than one build configuration, but I'll have to check with our SW team on how to main tain two different sysconfigurations.

  • I'm not able to find an answer for this so I'm going to move this posting over to our CCStudio group.

  • I'm not sure this is possible (to have a mix of sysconfig and non-sysconfig in the same project). I will need to follow up with engineering. I will keep you posted of my findings

  • SysConfog and non-SysConfig is possible in the same project.  In fact I think we should really create a little app note that talks about how to do it as I can see some people starting with SysConfig but then at some point wanting to take ownership of the generated code.  One nice way of doing that would be to have one config that uses sysconfig and another that does not.

    Whether or not SysConfig is used is based on if there is a .syscfg in the project and if it is excluded or not.  For example I can create a new build configuration.  It will copy an existing one.  THen I change my config to the new one and exclude the .syscfig file.  Now SysConfig would be used in the build for the original config but not for the new one.

    Here is my original config build output:

    **** Build of configuration Debug for project gpio_multi_led_blink_am243x-lp_r5fss0-0_nortos_ti-arm-clang ****
    
    /Applications/ti/ccs1100b11/ccs/utils/bin/gmake -k -j 7 all -O 
     
    Building file: "../example.syscfg"
    Invoking: SysConfig
    "/Users/a0792138/ti/sysconfig_1_8_1/sysconfig_cli.sh" -s "/Users/a0792138/ti/mcu_plus_sdk_am243x_08_00_00_21/.metadata/product.json" --script "/Users/a0792138/workspace_v11b11_2/gpio_multi_led_blink_am243x-lp_r5fss0-0_nortos_ti-arm-clang/example.syscfg" --context "r5fss0-0" -o "syscfg" --part ALX --package ALX --compiler ticlang
    Running script...
    Validating...
    Generating Code (example.syscfg)...

    Here is the output of my new config where I excluded the .syscfg file:

    **** Build of configuration NEW for project gpio_multi_led_blink_am243x-lp_r5fss0-0_nortos_ti-arm-clang ****
    
    /Applications/ti/ccs1100b11/ccs/utils/bin/gmake -k -j 7 all -O 
     
    Building file: "../main.c"
    Invoking: Arm Compiler

    You can see in the second one that it goes straight to compiling.  I did a clean inbetween.

    You can also have different .syscfg files on a per configuration basis.

    Note that sometimes the device and variant information is passed to sysconfig from the build options.  That can be set on a per config basis.  However usually it is actually included in the .syscfg file itself.

    For example at the top of my .syscfg file I see:

    /**
    
     * These arguments were used when this file was generated. They will be automatically applied on subsequent loads
    
     * via the GUI or CLI. Run CLI with '--help' for additional information on how to override these arguments.
    
     * @cliArgs --device "AM243x_ALX_beta" --package "ALX" --part "ALX" --context "r5fss0-0" --product "MCU_PLUS_SDK@07.03.01"
    
     * @versions {"data":"2021040816","timestamp":"2021040816","tool":"1.8.1+1900","templates":null}
    
     */

    So if I want to use a different device then I have to edit the build options in the project to specify a different device here:

    It may be a better approach to have 2 separate sysconfig files for the different devices.  Especially as they likely use different SDKs as well.

    Regards,

    John

  • Thanks again for your time and effort.

    In my situation, i can see that sysconfig is no longer part of the build process when the .syscfg file is excluded from build. The device family and variant stay greyed out though. Even completely deleting the .syscfg file does not make the family or variant choice available.

    It looks like how i imagined this to work might not actually be how it works.

    The device we investigate as alternative is the TM4C123GH6PMT7. When i create a new project based on this controller, the family gets greyed out, fixed on "ARM". With the MSP432P401R same story, the family gets greyed out, fixed on "MSP432". In the latter situation, CCS allows me to select a MSP430 variant, but then recreates the project for the new family. It looks like CCS commits to a family, and that it is just not possible to have configurations with controllers belonging to different families in a single project. Is this correct?

  • Ki is going to check on that but that selection may be fixed when the project is created with SysConfig enabled.  You can workaround that though.  When selecting a device what it does is setup the default build options and setup the device in your target configuration (debug).  The first is not a big deal as you are likely setting your own options.  The second can be worked around by unchecking the box to automatically manage the target configuration and instead just have your own ccxml files.  You would need to do that anyway as the project assumes a single one.

    Given the use of 2 different devices you will want 2 different syscfg files as the settings will be different.

    In the SysConfig options for the project you then pass the device as an option.

    Below are captures of my sysconfig build options where I specify a different device per config.  And then the second set of captures shows those devices in use by sysconfig.  If you get the device name wrong sysconfig will complain and then let you select the device.  In your case the software package will also be different and you will have to select that.

  • I do not know how much to blame on sysconfig anymore. It seems like sysconfig enabled projects lock the device variant, but when creating just a new empty project with the TM4C or MSP432 (no rtos, no sysconfig), the family is already locked.

    Attached screenshot: Properties of a new CCS project (simple main.c projoect) displaying device family already locked, and sysconfig not present.

    Edit: Maybe a better route would be one directory(Git repo), in there the common source dir, and the two different configurations as different CCS project - directories. And in the two CCS projects, refer to the common source dir as linked folder?

  • For the example in the screen shot did you try clicking in the box for the device.  When I create a new project for a tm4c123 with the wizard it looks like your capture but I can click in the box and change the device.

    2 projects with a linked folder with common source is a good idea.

    John

**Attention** This is a public forum