• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 82 subscribers
  • Views 169 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.

CCSTUDIO-THEIA: Not able to switch the chip in SYSCFG GUI

Bhargav Jyoti Saikia
Prodigy 121 points

Part Number: CCSTUDIO-THEIA
Other Parts Discussed in Thread: TMS320F28379D, TMS320F28375D, SYSCONFIG, C2000WARE

Hi team,

I am not able to use the syscfg GUI tool to change the chip selection, default chip is TMS320F28375D, and i want to switch to TMS320F28379D, but the syscfg tool display nothing when i click on the drop-down arrow button, and all settings has gone. When I open syscfg again, CCS behaves the same way. Looks like this is a software bug and other users have reported this long ago but still not resolved. Earlier I was able to switch properly but now after some CCS update not able to do so. To make things worse, I am not able to switch to earlier CCS versions. If I open CCS v20.1, it is still opening CCS v20.4.1

CCS version: 20.4.1.4

Syscfg version: 1.26.0+4407

Compiler version: TI v22.6.3.LTS

Kindly help to resolve this critical issue or help in identifying in which CCS version or Syscfg version, this was working fine and how to switch to that.

Thanks,

Bhargav Saikia.

image.png

  • 0
    TI__Expert 5055 points

    Hi Bhargav,

    Thank you for your question. Sorry for the late reply. I'll look into the issue and get back to you.

    Thanks,

    Ira

  • 0 in reply to Ira Thete
    Prodigy 121 points

    Hi Ira,

    Thank you for your support. Hope there will be quick resolution, since this is a critical issue and not able to use Syscfg tool in any way.

    Thanks,

    Bhargav.

  • 0 in reply to Bhargav Jyoti Saikia
    TI__Expert 5055 points

    Hi Bhargav,

    This is a known issue with this particular version. For the time being can you try this workaround?

    Manually Edit the .syscfg File

    The most reliable workaround — confirmed working — is to bypass the GUI entirely and edit your .syscfg file as plain text, adding @cliArgs comment blocks at the top that force the correct device configuration [3].

    Step-by-step:

    1. Close the SysConfig GUI editor in CCS
    2. In Project Explorer, right-click your .syscfg file → Open With → Text Editor
    3. Replace or add the following comment block at the very top of the file:

    /**
    * @cliArgs --device "F2837xD" --part "F2837xD_337ZWT" --package "F2837xD_337ZWT" --context "CPU1" --product "C2000WARE@5.04.00.00"
    * @v2CliArgs --device "TMS320F28379D" --package "337ZWT" --context "CPU1" --product "C2000WARE@5.04.00.00"
    * @versions {"tool":"1.26.0+4407"}
    */

    ️ Adjust these values for your setup:

    • Replace 337ZWT with your actual package (e.g., 176PTP if that's your chip variant)
    • Replace C2000WARE@5.04.00.00 with your installed C2000Ware version
    • Replace CPU1 with CPU2 if targeting the second core, or duplicate the block for dual-core
    1. Save the file, then reopen it in the SysConfig GUI — it will now read the correct device from the comment block [3]
    2. Critical: Apply this change to both FLASH and RAM build configurations to prevent include path mismatches when switching between them
    Additionally, in your CCS project's SysConfig build properties (Project → Properties → Build → SysConfig), leave the Board, Device, and Part fields empty — SysConfig will read the device from the .syscfg comment block instead

    Regarding the CCS Version Switching Issue

    The fact that opening CCS v20.1 launches v20.4.1.4 instead points to an installation conflict or PATH/environment variable issue — likely your system's PATH is resolving to the newer CCS installation first. To investigate: check your system PATH for CCS entries, verify that v20.1 is actually installed (not just a shortcut), and consider a clean reinstall if needed. This is a separate issue from the SysConfig bug but worth resolving independently.

    The .syscfg text edit workaround is your most direct path forward right now. If you share your C2000Ware version and the exact package of your F28379D (e.g., 337ZWT vs. 176PTP), the @cliArgs block above can be tailored precisely to your setup. It's also worth confirming whether your project targets CPU1, CPU2, or both cores, as that affects the --context argument.

    Thanks,

    Ira