• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 56 subscribers
  • Views 334 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.

LAUNCHCC3235MOD: Sysconfig not setting up GPIO pull-ups correctly

Chris Miller79
Intellectual 460 points
Part Number: LAUNCHCC3235MOD
Other Parts Discussed in Thread: SYSCONFIG

I started a thread in the WiFi Forum:

e2e.ti.com/.../5107174

Shlomi Itzhak has confirmed that this fault was introduced some time between CCS 10 and CCS 12, and I believe has pinpointed the issue to being misoperation of the tools - I assume Sysconfig.

I wonder if somebody in the 'Tools' side could possibly take a look at this.  Referring to the thread above will provide (very) full detail of what he and I have tried.

I have also just discovered that trying to use GPIO9 as an output does not work, which I suspect is a similar kind of problem.

Other GPIOs (some inputs, some outputs) are working as expected on the same project.

I'm happy to provide a zipped copy of my project should that be required, but preferably to a PM rather than publicly.

  • 0
    Intellectual 460 points

    I have spent much of today trying to get to the bottom of these issues, focusing on the misoperation of GPIO9.  This was particularly vexing as we have just had 50 bare boards made which use GPIO9, and the first one I've built up of course doesn't work with that GPIO out of action

    First - to check my hardware, I loaded up the 'power measurement' example which just happens to use GPIO9 to operate the blue LED on the LAUNCH board - I tacked an LED/ballast resistor onto GPIO9 so I could see what was happening

    Building that in CCS 12.6 using sysconfig 19 works - the LED starts flashing as expected.

    I then incrementally added the other peripherals my board needs, testing that the LED continued to flash as expected - it did.

    I then literally copied the two .syscfg files across from the power measurement project to my project.  It needed a few lines copied from my old common.syscfg file (ones to do with the Simple link network applications), but at that point, GPIO9 was working for me.  I saved the project at that point

    The next thing I did was to change the 'Display' device to be Send only, as I don't want or need the ability to accept input from the 'console' port, but its useful for debug output.

    At this point, GPIO9 stopped working.

    I then did a compare between the newly non-working common.syscfg and the saved version, and noticed that

    In the working file:

    The first GPIO.AddInstance() was called GPIO1

    There were then 7 more addinstances with GPIO4 missing

    In the broken file:

    The first GPIO.AddInstance() was called GPIO2

    I manually renumbered the GPIO instances from 1 monotonically (changing the AddInstance lines and the later lines roviding the config for each gpio).

    I then re-built and the application now operates GPIO9 again.

    Tenatative conclusion:

    It seems that the recent versions of Sysconfig do not correctly handle the deletion of GPIOs.

    I have more work to do to find out whether my hand-fixed .syscfg file will remain working as I tweak things.

    Obviously, this should not be necessary - I should only be tweaking these files through the SYCFONFIG GUI, but it seems this is not to be trusted....

  • 0 in reply to Chris Miller79
    Intellectual 460 points

    Is this forum active?

  • 0 in reply to Chris Miller79
    TI__Guru**** 449351 points

    Sorry for the delayed response. I have notified engineering of the issues you have discussed.

  • 0 in reply to Ki
    TI__Expert 5945 points

    Chris,

    The names of the variables in the .syscfg script are not preserved anywhere after the script runs.  They exist only to provide a variable name to use when applying the settings.  They are chosen by adding a number to the end of the module name for each module in the setup.  When you see a case where a number is missing, the tool has assigned that number a module that was implicitly brought in by another module.  For instance, if you add an NVS, it will pull in a GPIO, and that GPIO will have a number associated with it in the script.  However, the script won't end up using that name as it's exclusively owned via the NVS and can be referred to via the NVS.  For this reason, changing the names of these variables in the script, and nothing else, should not produce different results.

    Let me see if I can see what you're seeing.  I don't need the whole project, but can you please send me the working and non-working .syscfg files that differ only in the variable renaming (you can PM me the files if you prefer)?  Since you said GPIO9 was working, and then stopped after changing something, can you send me the .syscfg file before that change, as well as after that change?

    Darian