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 Sys

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. For control code, confirm whether timing comes from a timer ISR, RTOS task delay, hardware PWM/ADC trigger chain, or a main loop poll before changing periods or priorities. Keil Project Checks Treat system.syscfg and ti msp dl config.c / ti msp dl config.h as the configuration source surface for Keil based MSPM0 projects that keep SysConfig outputs at the project root. Treat a Keil .uvprojx as the project entrypoint, the scatter file as the linker source of truth, and Objects/ , Listings/ , .uvoptx , build logs, and generated outputs as inspection only unless a request explicitly targets them. For a project's application code, follow its own source layout rather than assuming CCS defaults. CMake / GCC / OpenOCD Checks Treat CMakeLists.txt , toolchain files, and OpenOCD .cfg files as the project entrypoints for CMake/GCC/OpenOCD projects. Build through the existing CMake build directory when present, for example cmake build cmake build debug target <target . MSPM0 OpenOCD flashing usually requires a TI MSPM0 capable OpenOCD build or TI extension branch. If OpenOCD reports unable to find a matching CMSIS DAP device , report that as probe discovery failure rather than firmware failure. Do not require CCS targetConfigs/ .ccxml when the active project uses OpenOCD instead of DSLite. FreeRTOS Checks If FreeRTOSConfig.h , FreeRTOS.h , task.h , xTaskCreate , or vTaskStartScheduler are present, treat the project as RTOS aware. Keep RTOS handling lightweight: respect existing task, queue, ISR, and blocking call boundaries; do not impose a specific framework architecture unless the user asks. Ambiguous Requests If the user omits important hardware parameters, do not silently choose risky values. For low risk defaults, use this skill's examples/ or local TI SDK examples, then tell the user which defaults were applied. For important parameters, ask before editing and offer a concrete recommendation. Important missing parameters include pin, peripheral instance, UART baud/data/parity/stop bits, Timer period, PWM frequency/duty/polarity, ADC channel/reference/sample time, DMA direction/source/destination, interrupt priority, and external module power/logic levels. Example: if the user asks "add a timer interrupt", ask which timer and period they want, and recommend a starter such as TIMG at 1 ms or 10 ms if they are unsure. External Modules And Hardware Debugging When asked to drive an external module, sensor, motor driver, servo, display, radio, or custom board: Ask for the module datasheet, schematic, pin map, supply voltage, logic level, communication protocol, and key parameters when they are not available. Verify wiring assumptions before blaming code: power, ground, pull ups, level shifting, reset/enable pins, boot pins, chip select, UART TX/RX crossover, I2C address, SPI mode, PWM polarity, and shared pins. If repeated attempts fail and SysConfig, build, flash, and code logic look correct, explicitly raise the possibility of wiring, power, module mode, datasheet mismatch, damaged hardware, or wrong test procedure. Separate "firmware looks correct" from "hardware proved correct". Reference Selection Read references only when needed: references/project workflows.md : .syscfg editing, CCS / Keil / CMake project layout, SDK schema lookup, SysConfig CLI, builds, DSLite/J Link, and OpenOCD. references/driverlib runtime rules.md : DriverLib usage, interrupts, clock tree, delays, and common runtime mistakes. references/hardware validation notes.md : verified Tianmengxing MSPM0G3507 lessons, HFXT warnings, flash/reset behavior, and real board caveats. references/debug backends.md : CCS DSS and OpenOCD/GDB probe, flash, breakpoint, retry, and manual unlock workflows. Use examples/ as one source for reusable tested patterns. Prefer scripts/list examples.py to inspect available examples before opening individual example files, but do not assume packaged examples outrank the user's existing project structure or official TI SDK examples. Examples Each reusable example should contain: Do not require users to drop full CCS projects into examples/ . Use scripts/capture example.py to extract a compact example package from a real project. When applying an example to a user project: Treat skill examples as proven references, not mandatory project templates. Copy only the needed .syscfg fields, generated name expectations, code pattern, or debugging lesson. Preserve the user's existing file layout and naming. If an example uses BSP/ , do not create BSP/ in the user project unless the user asked for that structure or the project already follows it. Prefer the user's local style when it conflicts with an example's directory names, wrapper names, or layering. Consider official TI SDK examples and local SDK metadata at the same or higher priority when they better match the user's board, SDK version, peripheral, or toolchain. For DMA UART examples, keep TX buffers per UART instance, avoid shared static printf buffers, and choose RX handling per port: ISR callback for the one port that needs immediate line parsing, UART poll() for extra receive ports, or TX only init for ports that do not receive. For periodic timer interrupts, configure the TIMER instance and interrupt in .syscfg , confirm the generated load value against the generated CPU clock, enable the generated IRQ in application code, and keep the ISR short. Tools Run bundled scripts with Python 3.10 or newer. serial console.py additionally requires pyserial ; if import fails, tell the user to run python m pip install pyserial . TI SDK, SysConfig, CCS/UniFlash, OpenOCD, and GDB remain external workflow dependencies and are not installed by this skill. python scripts/check syscfg.py <project dir : static project check for .syscfg , generated files, pins, init spelling, project shape, CCS/Keil/CMake

mspm0-ccs