• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 54 subscribers
  • Views 1740 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

[FAQ] Sysconfig known issue when using custom boards – workaround for SimpleLink CC13x2_26X2 SDK v. 3.30.00.xx or 3.40.00...

CCS/CC1310: Issues with installing and using SysConfig in CCS10 SDK 13x0 4.20 and stand alone SysConfig and now missing RTC configuration in SysConfig

Ralph Deffke
Expert 2915 points
Part Number: CC1310
Other Parts Discussed in Thread: SYSCONFIG, , SYSBIOS

Tool/software: Code Composer Studio

Hi there,

trying to use the long expected SysConfig tool caused some time intense trial as I could not manage to find a clean and compete documentation how to install and use it. In the related thread in this forum is also information missing for somebody not having worked with this tool before.

I am designing the firmware for a custom board based on the CC1310F32 and as in the Academy suggested using the empty project to start with.

I could not manage to find the SysConfig file nor tool or how to install it in CCS10

So what I did was that I used the stand alone SysConfig tool to generate my configuration and saved it to the project path.

Suddenly when I opened it, CCS10 messaged that the SysConfig tool is missing and installed it automatically,

However, when I opened the sysconfig file my previous in the standalone version done setup was gone.

While configuring again, conflict messages came up and I used the smart option to ignore them to generate the files.

However, I could not see the files in the project as I did not see any comment in the documentation that these files are generated in the output configuration directory (Debug or Release)

I closed and opened changed configuration but I could not get rid of these conflict messages.

However right after closing and opening the internal SysConfig the RTC configuration option disappeared in SysConfih.

I then opened the ssconfig file in an external editor and deleted the sections I thought causing the conflict.

As result I can confirm that CCS19 sysconfig and stand alone version 1.5.0+1397 are not really compatible but I manged so far.

However, how do I get the RTC setup back ?

here are the file showing the conflicts

/**
 * 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 "CC1310RSM" --package "RSM" --part "Default" --product "simplelink_cc13x0_sdk@4.10.01.01"
 * @versions {"data":"2020052512","timestamp":"2020052512","tool":"1.5.0+1397","templates":"2020052512"}
 */

/**
 * Import the modules used in this configuration.
 */
const GPIO  = scripting.addModule("/ti/drivers/GPIO", {}, false);
const GPIO1 = GPIO.addInstance();
const GPIO2 = GPIO.addInstance();
const GPIO3 = GPIO.addInstance();
const GPIO4 = GPIO.addInstance();
const GPIO5 = GPIO.addInstance();
const GPIO6 = GPIO.addInstance();
const Power = scripting.addModule("/ti/drivers/Power");
const RTOS  = scripting.addModule("/ti/drivers/RTOS");

/**
 * Write custom configuration values to the imported modules.
 */
GPIO1.mode                          = "Output";
GPIO1.initialOutputState            = "High";
GPIO1.$name                         = "Board_LED";
GPIO1.gpioPin.$assignAllowConflicts = "DIO_0";
GPIO1.pinInstance.$name             = "Board_PIN0";

GPIO2.$name                         = "ScrewSense";
GPIO2.interruptTrigger              = "Rising Edge";
GPIO2.callbackFunction              = "SenseScrewISR";
GPIO2.gpioPin.$assignAllowConflicts = "DIO_1";
GPIO2.pinInstance.$name             = "Board_PIN1";

GPIO3.interruptTrigger              = "Low";
GPIO3.callbackFunction              = "HallTriggerISR";
GPIO3.$name                         = "Trigger";
GPIO3.gpioPin.$assignAllowConflicts = "DIO_6";
GPIO3.pinInstance.$name             = "Board_PIN2";

GPIO4.$name             = "Hall1";
GPIO4.pinInstance.$name = "Board_PIN3";

GPIO5.$name                         = "Hall2";
GPIO5.gpioPin.$assignAllowConflicts = "DIO_8";
GPIO5.pinInstance.$name             = "Board_PIN4";

GPIO6.$name             = "Hall3";
GPIO6.pinInstance.$name = "Board_PIN5";

Power.policyFunction = "PowerCC26XX_doWFI";

/**
 * These are the reserved peripherals and settings in this configuration
 */
const iGPIO1                      = scripting.addPeripheral("GPIO");
iGPIO1.$numPins                   = 6;
iGPIO1["0"].$assignAllowConflicts = "DIO_0";
iGPIO1["1"].$assignAllowConflicts = "DIO_1";
iGPIO1["2"].$assignAllowConflicts = "DIO_6";
iGPIO1["3"].$assign               = "DIO_7";
iGPIO1["4"].$assignAllowConflicts = "DIO_8";
iGPIO1["5"].$assign               = "DIO_9";
iGPIO1.$name                      = "MyGPIO1";
const iJTAG1                      = scripting.addPeripheral("JTAG");
iJTAG1.$name                      = "MyJTAG1";
iJTAG1.$assign                    = "JTAG";
iJTAG1.TDI.$assign                = "DIO_4";
iJTAG1.TDO.$assign                = "DIO_3";
iJTAG1.TMSC.$assign               = "JTAG_TMSC";
iJTAG1.TCKC.$assign               = "JTAG_TCKC";
const iRTC1                       = scripting.addPeripheral("RTC");
iRTC1.$name                       = "MyRTC1";
iRTC1.$assign                     = "RTC0";
iRTC1.DMA_RTC.$used               = false;
const iWDT1                       = scripting.addPeripheral("WDT");
iWDT1.$name                       = "MyWDT1";

/**
 * Pinmux solution for unlocked pins/peripherals. This ensures that minor changes to the automatic solver in a future
 * version of the tool will not impact the pinmux you originally saw.  These lines can be completely deleted in order to
 * re-solve from scratch.
 */
GPIO4.gpioPin.$suggestSolution = "DIO_2";
GPIO6.gpioPin.$suggestSolution = "DIO_5";
iWDT1.$suggestSolution         = "WDT0";

and here the cleaned one

/**
 * 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 "CC1310RSM" --package "RSM" --part "Default" --product "simplelink_cc13x0_sdk@4.10.01.01"
 * @versions {"data":"2020052512","timestamp":"2020052512","tool":"1.5.0+1397","templates":"2020052512"}
 */

/**
 * Import the modules used in this configuration.
 */
const GPIO  = scripting.addModule("/ti/drivers/GPIO", {}, false);
const GPIO1 = GPIO.addInstance();
const GPIO2 = GPIO.addInstance();
const GPIO3 = GPIO.addInstance();
const GPIO4 = GPIO.addInstance();
const GPIO5 = GPIO.addInstance();
const GPIO6 = GPIO.addInstance();
const Power = scripting.addModule("/ti/drivers/Power");
const RTOS  = scripting.addModule("/ti/drivers/RTOS");

/**
 * Write custom configuration values to the imported modules.
 */
GPIO1.mode                          = "Output";
GPIO1.initialOutputState            = "High";
GPIO1.$name                         = "Board_LED";
GPIO1.gpioPin.$assignAllowConflicts = "DIO_0";
GPIO1.pinInstance.$name             = "Board_PIN0";

GPIO2.$name                         = "ScrewSense";
GPIO2.interruptTrigger              = "Rising Edge";
GPIO2.callbackFunction              = "SenseScrewISR";
GPIO2.gpioPin.$assignAllowConflicts = "DIO_1";
GPIO2.pinInstance.$name             = "Board_PIN1";

GPIO3.interruptTrigger              = "Low";
GPIO3.callbackFunction              = "HallTriggerISR";
GPIO3.$name                         = "Trigger";
GPIO3.gpioPin.$assignAllowConflicts = "DIO_6";
GPIO3.pinInstance.$name             = "Board_PIN2";

GPIO4.$name             = "Hall1";
GPIO4.pinInstance.$name = "Board_PIN3";

GPIO5.$name                         = "Hall2";
GPIO5.gpioPin.$assignAllowConflicts = "DIO_8";
GPIO5.pinInstance.$name             = "Board_PIN4";

GPIO6.$name             = "Hall3";
GPIO6.pinInstance.$name = "Board_PIN5";

Power.policyFunction = "PowerCC26XX_doWFI";

  • 0
    Expert 2915 points

    Further I figured that the JTag definition is missing as well.

    And that make me assume that nin CCS 10 this syntax does not work

    const iJTAG1                      = scripting.addPeripheral("JTAG");

  • 0 in reply to Ralph Deffke
    TI__Guru 58425 points

    Hi Ralph,

    Could you share the steps you try to follow to set this up for my reference? I'm running the same "stand-alone" version and it works for me (but as far as I know, CCS10 ships with a lower version while CCS10.1 ships with 1.5.0).

    A few things that strikes me as odd, JTAG and RTC is typically not supported SysConfig modules. The RTC has no peripheral driver and thus there is nothing to configure, same goes for JTAG as this has fixed pins (this is on CC1310). As such, these options should never have been available in the first place in SysConfig.

  • 0 in reply to IUsedToBeARealPerson (M-W)
    Expert 2915 points

    HI MW,

    well, I would expect 'configuration' in SysConf as it can be conflicting with the GPIO setup.

    As you know Jtag can be configured in 2-pin and 4-pin mode, fine so that would give the TDO and TDI pin free for other use. However, the TDO is as well usable for target UART.

    Same with RTC, not sure if I mix up with other manufacturers, but you may configure the RTC to toggle a pin reaching a certain time waking up the core. Would be nice to have that code auto inserted.

    As an application engineer I would prefer to have these scenarios reflected in SysConf garfically even so there is nothing to configure at this stage. However, I would see SysConf as well changing the .ccxml file e.g. if TDO/TDI pins are used for GPIO the debugger should be forced to set to 2-pin advanced cJtag and target UART should be forced to set to on chip UART. The latter point of view is a bit weak I agree.

    OK now the steps I went in details.

    Versions

    SysConfig 1.5.0+1397

    CCS 10.1.0.00010

    Steps

    -importing empty project from SDK 4,20.xxxx

    -renaming project files to the ftarget project names and to be able to have an 'untouched' empty project in the same workspace.

    -no documentation how to install SysConfig in the IDE, therefor using standalone SysConfig. Both IDE and SysConfig are 'virgin' and not used before with any .syscfg file at that point

    -selecting chip type rather the a board, at this point JTag AND RTC show up in STA SysConfig ! selected those as present and in use ( remember you even can use Jtag IO's if no debug is required)

    -Saving created files in the projects workspace

    -opening the .syscfg with dblclick in CCS, CCS runs the installation of the IDE internal version of SysConfig.

    -now IDE's sysconfig shows port conflicts as it has changed the GPIO ports, and I could not manage using SysConfig to get rid of these conflicts and hence generating the output files without manually changing the .syscfg file.

    Refer to the generated .syscfg files in previous post.

    One final remark, when ever I decide to use TDI/TDO as GPIO after generating the outputfiles currently SysConfig will never generate the output files.

    You should seriously review these scenarios

    Best wishes

    Ralph

  • 0 in reply to Ralph Deffke
    TI__Guru 58425 points

    Hi Ralph,

    Are you using CC1310 as the topic suggest? As far as I know the latest SDK for this device is 4.10. Just wanted to make sure we are looking at the correct device as the CC13x2 series for example have SysConfig support in the SDK while this is standard in the CC13x0 as of today.

    SysConfig is still quite new and it might not be super clear yet on how it is supposed to be used. For the CC13xx and CC26xx devices (if we focus on these), only the "Software" and "Hardware" section is what is mainly used. The "Reserved Peripherals" can of course be used if you want, but you do not use this "view" to configure the device as such. 

    The "Reserved Peripherals" allows you to put down hard dependencies that you want to exclude from the SW point of view. For example, you can add "JTAG" here to be super sure that the SysConfig do not allow you to for example configure usage of the TDO and TDI pins in the "Software" view. It does not in any way alters the JTAG from the debugger point of view, SysConfig is not anyway debugger related, it only allows for the peripheral configuration, not the debugger ccxml (not saying it could not do this in the future but it is not as of today).

    So say that you want a 2/4 wire JTAG setup where you might want to re-use the TDO/TDI pins in SW, this is fine even with you not checking the "reserve JTAG" box, the only thing this "box" does is make sure that you get hard conflicts if you try to use the "reserved peripheral" or any of the IOs it uses.

    The same goes with RTC here, it only really says "no one can use the same peripheral with thisDMA channel". This have no affect at all as there is no "RTC driver" which means there is nothing to configure in the first place. The reason for the RTC not being in SysConfig "Software" view in the first place is because it do not exist (as I mentioned above) any actual driver for it. Usage of the RTC is masked in the SDK by the "Clock" module which allows you to schedule things based on the RTC:

    https://dev.ti.com/tirex/explore/content/simplelink_cc13x2_26x2_sdk_4_20_00_35/docs/tirtos/sysbios/docs/cdoc/ti/sysbios/knl/Clock.html

    This is intentional as the RTC as a hardware is considered "owned" by the kernel and the user is expected to use it via the Clock module (so there is no unexpected changes to the RTC peripheral setup). That said, there is room for one user configured channel but how to set this up in a bit hidden and it is part of the .cfg file used by XDC tools (Clock depends on Timer from a SysBios perspective):

    https://dev.ti.com/tirex/explore/content/simplelink_cc13x2_26x2_sdk_4_20_00_35/docs/tirtos/sysbios/docs/cdoc/ti/sysbios/family/arm/cc26xx/Timer.html

    I guess it is easier to consider the "Clock" module (and DPL) the RTC "driver" for these devices. As the Clock module is considered part of the kernel, then it is also configured using the kernel .cfg file instead of the SysConfig one. In the future, this might be part of SysConfig as well but as of today, SysConfig only touches the peripherals exposed by TI Drivers.