MSPM0 Skill

---
name: mspm0-ccs
description: Tool-neutral CLI agent rules for TI MSPM0 development with Code Composer Studio, Keil/uVision, CMake/GCC/OpenOCD, SysConfig, and DriverLib. Use when an agent needs to inspect or modify MSPM0 projects, edit .syscfg configuration, avoid generated SysConfig/build files, use DriverLib APIs, validate SysConfig output, package reusable MSPM0 examples, or work on NUEDC-style MSPM0 embedded firmware.
---

# MSPM0 Agent Skill

Use this skill for TI MSPM0 firmware projects that use SysConfig and DriverLib through CCS / CCS Theia, Keil/uVision, or CMake + Arm GNU Toolchain + OpenOCD workflows. It is intended for Claude Code, OpenCode, OpenClaw, Continue, Cursor, Codex, and similar CLI/editor agents.

## Default Workflow

1. Locate the project `.syscfg` or `system.syscfg`, editable source files, generated `ti_msp_dl_config.h`, and the active project entrypoint: `targetConfigs/*.ccxml` for CCS, `*.uvprojx` plus scatter file for Keil/uVision, or `CMakeLists.txt` plus OpenOCD `.cfg` files for CMake/GCC/OpenOCD.
2. Run `python scripts/check_syscfg.py <project-dir>` when this skill is available.
3. Read `.syscfg` metadata: device, package, SDK product, SysConfig version, modules, instances, pins, clocks, and interrupts.
4. Inspect generated `ti_msp_dl_config.h` for macro names, IRQ names, instance names, and the exact SysConfig init function spelling.
5. Before adding unfamiliar SysConfig fields, inspect the user's existing `.syscfg`, `examples/*/manifest.json`, TI SDK examples, or `source/ti/driverlib/.meta/*.syscfg.js`.
6. Modify the smallest relevant `.syscfg` and application-code surface.
7. By default, make the smallest evidence-based `.syscfg` edit and run `python scripts/run_sysconfig.py <project-dir>` before rebuilding. Use CCS SysConfig MCP only when the user explicitly requests it or the current session already exposes a confirmed SysConfig MCP tool.
8. If flashing or debugging, run `python scripts/detect_probe.py` or `python scripts/check_syscfg.py <project-dir> --probe` before selecting a backend. Confirm the configured probe matches the connected hardware and prefer a System Reset after programming.

## Core Rules

- Treat `.syscfg` as the source of truth for pinmux, peripheral setup, clocks, interrupts, DMA ownership, and generated initialization.
- Prefer SysConfig + DriverLib for GPIO, UART, PWM, Timer, ADC, I2C, SPI, DMA, and clock setup.
- Do not hand-edit generated outputs such as `Debug/ti_msp_dl_config.c`, `Debug/ti_msp_dl_config.h`, the project-root `ti_msp_dl_config.c` / `ti_msp_dl_config.h` pair in Keil layouts, `device_linker.cmd`, `Objects/`, `Listings/`, object files, maps, or `.out` files.
- Preserve `.syscfg` metadata such as `@cliArgs`, `@v2CliArgs`, `@versions`, `--device`, `--package`, and `--product`.
- Do not guess generated names. Read `ti_msp_dl_config.h` and use the local macros and the local init function spelling, such as `SYSCFG_DL_init()`.
- Do not invent SysConfig fields, enum values, device metadata, board names, package names, or tool versions. Validate against local examples, SDK metadata, or SysConfig CLI.
- New SysConfig releases may explicitly recommend the CCS SysConfig MCP. This skill does not probe for or require that unverified backend by default: use it only when the user asks for MCP or the current session already exposes a confirmed SysConfig MCP tool. Otherwise use a minimal manual edit followed immediately by standalone CLI validation, and state that this does not provide the MCP's interactive mutation feedback.
- Preserve unrelated user code, comments, copyright headers, project layout, and existing `.syscfg` settings. If a requested feature requires a larger rewrite, explain why before making it when possible.
- Do not change device, package, SDK, compiler, CCS version, board, or debug probe without user confirmation.
- If the user asks only to "flash" or "debug", do not silently assume J-Link, XDS110, CMSIS-DAP/DAPLink, or ST-Link. Detect the connected probe first. If detection is unknown, multiple probes are connected, or the project configuration conflicts with the physical probe, stop and ask the user which backend to use.
- Treat an empty probe-detector result as inconclusive, not proof that no probe is connected. Some DAPLink/CMSIS-DAP and XDS110 devices appear only as Windows `USBDevice`, `HIDClass`, or `Ports` children. Inspect OS USB/PnP devices and serial ports (`python scripts/serial_console.py --list` on Windows), then try the intended backend's read-only probe/list command or ask the user before concluding the probe is absent.
- If SysConfig emits warnings, report them separately from build/flash success. Do not call a warning-producing generation "clean".
- If hardware behavior is not verified on a connected board, say that validation stopped at source, SysConfig, or build level.

## Board-Specific Pin Caution

When the user explicitly says the board is LCKFB Tianmengxing MSPM0G3507:

- Avoid choosing A21/PA21, A23/PA23, A02/PA02, and A18/PA18 for ordinary user-requested pin assignments unless the user asks for those pins or the local project already deliberately uses them.
- PA10 and PA11 are also marked as special, but Tianmengxing routes them as the default UART pins. When choosing pins for a UART, consider PA10 TX and PA11 RX first if they are free and match the requested UART instance. For GPIO, PWM, SPI, I2C, timer, or other non-UART uses, continue to treat PA10/PA11 as special pins and prefer other available pins.
- If the user asks to drive or reuse one of these special pins for a non-default purpose, remind them of the Tianmengxing board note. In particular, explain that repurposing PA10/PA11 can conflict with or remove the board's default UART connection.
- Do not silently move an existing project away from these pins. Explain the board caveat first, then ask or proceed according to the user's intent.

## Project Shape Checks

- Simple projects usually keep most logic in `main.c`, `empty.c`, or a small number of files. It is acceptable to make narrowly scoped edits there.
- Framework projects often have multiple source directories such as `app/`, `bsp/`, `components/`, `core/`, `drivers/`, `hal/`, `middleware/`, or `tasks/`. First identify ownership boundaries before adding peripherals or changing control logic.
- Do not assume every MSPM0 project is CCS-like or single-file. A framework project can still use CCS, Keil, or CMake/GCC/OpenOCD.