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.

MSPM0G5187: How to disable USB - UART, GPIO Dependencies in Sysconfig

Part Number: MSPM0G5187
Other Parts Discussed in Thread: SYSCONFIG,

Hello team,

 

Why do we have to make dependencies in GPIO, UART?

 

If I remove dependencies in sysconfig, related variables doesn't automatically generated.

So, it makes error in "family.c". -> Debug fail...

 

If this dependency is enabled, they occupy use-less pins.

How can I remove dependency without error?

 

Thanks 

 

image.png

 

image.png

  • HI Ryan,

    In the MSPM0G5187, SysConfig uses a dependency model to ensure that high-level software components (like Power Management or DriverLib) know which hardware resources are active. When you see a "Dependency" in SysConfig for a module like GPIO or UART, it is often linking that peripheral to a specific Instance Name or DMA/Event channel. You can try the following to try and mitigate this issue:
    Method 1: Use package-less or virtual instances. If you want the code to recognize the UART or GPIO module exists but don't want it tied to a physical pin yet:
    • In SysConfig, click on the UART or GPIO instance.
    • Look for the Pinmux section.
    • Uncheck the individual pins (TX, RX, etc.).
    • If SysConfig forces a pin assignment, you can often select "Any" or move them to pins you know you aren't using.
    • The #define names stay in the code (so family.c builds), but the pins are not actually initialized in the hardware.
    Method 2: Modify family.c. If you are moving away from a TI LaunchPad example and building your own hardware:
    • Remove the dependency in SysConfig.
    • Go into family.c and comment out or delete the code that references the missing UART/GPIO variables.
    • Example projects are "hard-wired" to look for specific LED or Debug UART pins. For a production board, you should remove these dependencies from the code itself rather than forcing SysConfig to maintain them.
    Method 3: Use the "Exclude from Build" option. If family.c is strictly for board-level testing (LEDs/Buttons) that you don't need:
    • Right-click family.c in the CCS Project Explorer.
    • Select Exclude from Build.
    • The compiler ignores the file entirely, and you can clean up your SysConfig without worrying about those specific errors.
    The error isn't a bug; it's a linkage between the GUI settings and the C code. To fix it without wasting pins, either unassign the pins inside the SysConfig module or delete the references inside family.c. Hope this helps!
    -Brian