• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 41 subscribers
  • Views 523 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.

Original question:

CC3220SF-LAUNCHXL: Migrate to new Syscfg

CC3220SF-LAUNCHXL: Migrate to new Syscfg

MJ
Intellectual 950 points
Part Number: CC3220SF-LAUNCHXL
Other Parts Discussed in Thread: SYSCONFIG, CC3220SF

Dear TI,

I have a project with old pin configuration, but now I want to switch to the new SysCfg because of its convenience.
A few months back I have also asked this question, but at that time the SDK v2.40 was not yet released.
I couldn't find the documentation to do this, so therefore I have a few questions:

  1. Currently I am using a software configuration for chip select of SPI communication. With new SysCfg, can I just simply remove the CS config from the SPI and add one to the GPIO?
  2. I am using a Open Drain configuration and no pull (GPIO_CFG_OUT_OD_NOPULL), but I can't find how to do that with SysCfg.
  3. How do I set the pin name that is used in the code?  I can set the name of a group of pins, but how do I use these pins then? Basically I would like to know what would be the equivalent of the old header file for configuration.

Thank you in advance,

Best regards,

MJ

  • 0
    Intellectual 950 points

    I did so more debugging today, but I raised more questions:

    4) My build fails because the sysconfig file requires SDSPI.h: "fatal error: ti/drivers/SDSPI.h: No such file or directory". Indeed this file does not exist in the both SDK v3.10 as v3.20, and if I try to google it, it seems that SDSPI.h is deprecated a while ago.
    How can I solve this issue?

    Also, I found out that the SysConfig auto-generates the old files. I can already see that question 1 & 2 don't work in my current config, and generated header file would answer my 3rd question.

    Therefore my final question:

    5) Is it recommended to switch to SysConfig files if you want these type of configurations? or should I stay with the old variant in that case.

  • 0 in reply to MJ
    TI__Mastermind 38980 points

    Hi MJ,

    1. SPI chip select is supported in SysConfig (I'm looking at the latest SDK 3.20). The label may also be called "SS Pin", but it is the same signal.
    2. Open drain is an output GPIO configuration. Once you choose the output mode, you can select open drain as the output type.
    3. The name for each peripheral instance is the name you use for TI Driver API calls. For example, Board_GPIO_BUTTON0.
    4. What version of the CC32xx SDK and CCS are you using?  Did you copy source code from an older SDK project? It sounds like you may have a mismatched driver library version. Try importing an example directly from the latest SDK and build.
    5. SysConfig does auto-generate your board files for you. All the functionality from the old board files should be in SysConfig, but if for some reason you do not want to use the GUI, you can exclude the .sysconfig file from the project to disable the auto-generation. You can find more information on SimpleLink Academy in the SysConfig Tool Basics lab: http://dev.ti.com/tirex/explore/node?node=AO3dBAhu05HBWXd.SPxt0g__fc2e6sr__LATEST

    Best regards,

    Sarah

  • 0 in reply to Sarah P
    Intellectual 950 points

    Dear Sarah,

    Thanks for your reply.

    It was indeed a mismatch between SDK version. My current project was on SDK 3.10 instead of SDK 3.20.
    After changing SDK version, and (re)copying the SysConfig file I got a totally different layout of the configurator.

    All questions are now answered, but I got an error and I guess it has to do with differences between CC3220MODASF and CC3220SF devices.

    I configured SysConfig to use the MOD edition of CC3220SF, and set my UART (used for Display UART) to port GPIO 01(TX) and GPIO02 (RX). For MOD version that would be:

    RX: UARTCC32XX_PIN_47_UART0_RX,

    TX: UARTCC32XX_PIN_46_UART0_TX,

    However, for the non-MOD version that is:

    RX: UARTCC32XX_PIN_57_UART0_RX,

    TX: UARTCC32XX_PIN_55_UART0_TX,

    When compiling I now get this error:

    tirtos_builds_CC3220SF_LAUNCHXL_release_gcc/Debug/configPkg/compiler.opt" -o"syscfg/Board.o" "syscfg/Board.c"
subdir_rules.mk:24: recipe for target 'syscfg/Board.o' failed
syscfg/Board.c:339:27: error: 'UARTCC32XX_PIN_47_UART0_RX' undeclared here (not in a function); did you mean 'UARTCC32XX_PIN_57_UART0_RX'?
     .rxPin              = UARTCC32XX_PIN_47_UART0_RX,
                           ^~~~~~~~~~~~~~~~~~~~~~~~~~
                           UARTCC32XX_PIN_57_UART0_RX
syscfg/Board.c:340:27: error: 'UARTCC32XX_PIN_46_UART0_TX' undeclared here (not in a function); did you mean 'UARTCC32XX_PIN_47_UART0_RX'?
     .txPin              = UARTCC32XX_PIN_46_UART0_TX,
                           ^~~~~~~~~~~~~~~~~~~~~~~~~~
                           UARTCC32XX_PIN_47_UART0_RX
gmake: *** [syscfg/Board.o] Error 1

    It seems that the pins are mixed up, and to make it a bit weirder:  for the CC3220MODASF LaunchPad I have used for testing, the config was set to "UARTCC32XX_PIN_57_UART0_RX" and "UARTCC32XX_PIN_55_UART0_TX". I noticed that the CC3220MODASF LaunchPad Altium files use the same P55/ P57 labels, while the actual pins are connected to pin 46 and 47.
    Is this a error from TI side, or am I mixing things up? And if it is an error in the SDK, how can I apply a quick fix while still using the new SysConfig setup?

  • 0 in reply to MJ
    Guru 75955 points

    Hi,

    Quick comment. Inside module is a QFN chip CC3220SF. From this reason all pin mapping at software side need to be related to CC3220SF QFN chip. Software side did not care about mapping pins to MOD package.

    Jan

  • 0 in reply to Jan D
    Intellectual 950 points

    I understand Jan, but what you are saying is not completely correct. The software side (in this case the SysConfig tool) does take this into account.
    You can select MOD version during initial setup, and it will show you the pin layout of the device as well.

    My point is that the SysConfig output files is mapping UART0 RX/TX on port 46/47 to UARTCC32XX_PIN_47_UART0_RX and UARTCC32XX_PIN_46_UART0_TX respectively.  If you check the datasheet of CC3220MODASF, then it is indeed correct that port 46&47 are used. However, the macro's that are used now, are for the original CC3220SF which is not correct.

    Either new macro mapping should be done (e.g. "UARTCC32XXMOD_PIN_47_UART0_RX") or port macro's of original CC32XX should be used.

  • 0 in reply to MJ
    TI__Mastermind 38980 points

    Hi MJ,

    SysConfig does not currently support viewing the module package. Jan is correct that the device only understands the QFN pins. So you would configure pins 55 and 57 in software, and this signal would occur on pins 46 and 47 of the module package.

    In the Pin Attributes table of the module datasheet (http://www.ti.com/lit/ds/symlink/cc3220mod.pdf), you will see the module (package) pins and their corresponding device (software) pins.

    Best regards,

    Sarah

  • 0 in reply to Sarah P
    Intellectual 950 points

    Dear Sarah,

    If it is not supported, it is kind of weird that you can select the "Mod" at the initial configuration of the SysConfig.
    Furthermore it is quite frustrating that you can't change this afterwards, but that is probably because it is in preview version.

    I changed the --package "Mod"  flag to --package "Default", and that fixed it.

    Thank you both for the effort.

    Best regards,

    MJ