Because of the Thanksgiving holiday in the U.S., TI E2E™ design support forum responses may be delayed from November 25 through December 2. Thank you for your patience.

  • State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 83 subscribers
  • Views 724 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TMS320F280025C: SysConfig: Embedded CLI parameters not working

Andreas Stolze
Prodigy 80 points
Part Number: TMS320F280025C
Other Parts Discussed in Thread: C2000WARE, SYSCONFIG

Hi,

I am using CSS 11.1.0.00011 as well as C2000Ware 4.00.00.00.

I integrated a SysConfig into my project. In the SysConfig view I specified the appropriate device, package and part. E.g.:

/**
 * 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 "F28002x" --package "80QFP" --part "F28002x_80QFP" --product "C2000WARE@3.01.00.00"
 * @versions {"tool":"1.11.0+2225"}
 */

/**
 * Import the modules used in this configuration.
 */
const can   = scripting.addModule("/driverlib/can.js", {}, false);
const can1  = can.addInstance();
const gpio  = scripting.addModule("/driverlib/gpio.js", {}, false);
const gpio1 = gpio.addInstance();

/**
 * Write custom configuration values to the imported modules.
 */
can1.$name                 = "CAN1";
can1.msgObjsUsed           = [1];
can1.can.$assign           = "CANA";
can1.can.can_rxPin.$assign = "ball.38";
can1.can.can_txPin.$assign = "ball.49";
can1.msgObj1.$name         = "msgObj0";
can1.msgObj1.msgID         = 123;
can1.msgObj1.flags         = ["CAN_MSG_OBJ_RX_INT_ENABLE","CAN_MSG_OBJ_USE_ID_FILTER"];

gpio1.direction         = "GPIO_DIR_MODE_OUT";
gpio1.qualMode          = "GPIO_QUAL_ASYNC";
gpio1.writeInitialValue = true;
gpio1.$name             = "CAN1_SILENTMODE";
gpio1.gpioPin.$assign   = "ball.3";

As generated by CSS/Sysconfig, default parameters are inserted into the syscfg-file: @cliArgs --device "F28002x" --package "80QFP" --part "F28002x_80QFP" --product "C2000WARE@3.01.00.00"

However, these parameters seem to be ignored when calling the SysConfig generation (ignored as ignored in generation, I do not expect them to show up in the CLI call):

Building file: "../LAUNCHXL-F280025C.syscfg"
Invoking: SysConfig
"C:/ti/ccs1110/ccs/utils/sysconfig_1.11.0/sysconfig_cli.bat" -s "C:/ti/C2000Ware_4_00_00_00/.metadata/sdk.json" -d "F28002x" --script "C:/_repos/arculus/sw/03_SW_Component/arculus_bms/LAUNCHXL-F280025C.syscfg" -o "syscfg" --compiler ccs
Running script...
subdir_rules.mk:9: recipe for target 'build-2008392257' failed
Error: cannot set '$assign' to 'ball.38': No option named ball.38 defined, valid options are
[...]

Of course, I could specify the command line parameters in the build config of my project, however this would be redundant.

Is this a bug or am I doing/expecting something wrong?

Thanks,
Andreas

  • 0
    TI__Genius 11736 points

    Hi Andreas,

    I am a bit confused on what your issue is. Are you referring as to why there seems to be a mismatch in the C2000ware version in the CLI args (C2000WARE@3.01.00.00 vs C2000WARE@4.00.00.00)? 

    This does not seem to be a huge issue, the console output confirms you are using the most updated C2000ware version. I myself have seen this a few times working on different projects, so I'm not sure what exactly the culprit is. There are many projects where it shows 4.00.00.00 but occasionally I do get 3.01.00.00 on my 4.00.00.00 projects. Nonetheless, this does not affect the version that the project is using, so that should not be a worry.

    If instead you are referring to a different issue, please let me know.

    Regards,

    Peter

  • 0 in reply to Peter Luong1
    Prodigy 80 points

    Hi Peter.

    No, the C2000Ware version is not the problem.

    The generation process of SysConfig fails: Error: cannot set '$assign' to 'ball.38': No option named ball.38 defined, valid options are

    However, when configuring explicitly --package 80QFP --part F28002x_80QFP via the SysConfig properties, it works:

    Because then the CLI is called with explicit arguments. In this case the generation is done with the right package and part.

    "C:/ti/ccs1110/ccs/utils/sysconfig_1.11.0/sysconfig_cli.bat" -s "C:/ti/C2000Ware_4_00_00_00/.metadata/sdk.json" -d "F28002x" --script "C:/_repos/arculus/sw/03_SW_Component/arculus_bms/LAUNCHXL-F280025C.syscfg" -o "syscfg" --package 80QFP --part F28002x_80QFP --compiler ccs
Running script...
Validating...
Generating Code (LAUNCHXL-F280025C.syscfg)...
[...]
Finished building: "../LAUNCHXL-F280025C.syscfg"

    I dont't want to define this explicitly in the build config since this information would be redundant: it is already stored in the SysConfig.

    I argue that this should also be not needed since the CLI states:

    "C:/ti/ccs1110/ccs/utils/sysconfig_1.11.0/sysconfig_cli.bat" --help
[...]
Note that the all arguments other than '--help' and '--version' may also be
 specified via the script with an embedded @cliArgs comment directive.
 E.g. // @cliArgs -d MSP432P401R

 If an argument is embedded in a script and explicitly specified via the CLI
 then precedence is given to the CLI arguments. Additionally, specifying
 "--board" or "--device" on the CLI will override any "--board" and "--device"
  arguments specified in the script.

    I would except the @cliArgs to be used in generation. Is this now more clear?

    BR,
    Andreas

  • 0 in reply to Andreas Stolze
    TI__Genius 11736 points

    Hi Andreas,

    Thank you for the clarification. While it does seem redundant to have to specify this information in both the syscfg file and the build config, that is typically how it is done. Refer to the following FAQ which specifies putting the package and part information into the build configuration: https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/910829/faq-how-do-i-add-sysconfig-support-pinmux-and-peripheral-initialization-to-an-existing-driverlib-project

    It does look like there is potentially a bug with the CLI argument generation within the syscfg file. Let me reach out for more information on this. In the meantime, it looks like your project can compile with the package and part information specified in the build config, so that would be the preferred method for now. 

    Regards,

    Peter

  • +1 in reply to Peter Luong1
    TI__Guru 52000 points

    As long as you pass -device, it will assume you are passing everything in and it doesn't look at parameters.

    Same with project properties. Remove the device and package info from the project properties and it will then look at the parameters in the file.

  • 0
    Prodigy 80 points
    Nima Eskandari said:

    As long as you pass -device, it will assume you are passing everything in and it doesn't look at parameters.

    Same with project properties. Remove the device and package info from the project properties and it will then look at the parameters in the file.

    Thank you Nima, this works.

    In a way, this is already documented:

    Additionally, specifying "--board" or "--device" on the CLI will override any "--board" and "--device" arguments specified in the script.

    However, I would like to see the help output being updated to also mention the overwrite of the --part  and --package.