mspm0-ccs

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

MSPM0 Agent Skill

MSPM0 Agent技能

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.

当您的TI MSPM0固件项目通过CCS / CCS Theia、Keil/uVision或CMake + Arm GNU Toolchain + OpenOCD工作流使用SysConfig和DriverLib时，可使用本技能。本技能适用于Claude Code、OpenCode、OpenClaw、Continue、Cursor、Codex及类似的CLI/编辑器Agent。

Default Workflow

默认工作流

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.

Run

python scripts/check_syscfg.py <project-dir>

when this skill is available.

Read
```
.syscfg
```
metadata: device, package, SDK product, SysConfig version, modules, instances, pins, clocks, and interrupts.
Inspect generated
```
ti_msp_dl_config.h
```
for macro names, IRQ names, instance names, and the exact SysConfig init function spelling.
Before adding unfamiliar SysConfig fields, inspect the user's existing
```
.syscfg
```
,
```
examples/*/manifest.json
```
, TI SDK examples, or
```
source/ti/driverlib/.meta/*.syscfg.js
```
.
Modify the smallest relevant
```
.syscfg
```
and application-code surface.
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.
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.

定位项目的
```
.syscfg
```
或
```
system.syscfg
```
、可编辑源文件、生成的
```
ti_msp_dl_config.h
```
，以及活跃项目入口点：CCS对应
```
targetConfigs/*.ccxml
```
，Keil/uVision对应
```
*.uvprojx
```
加分散加载文件，CMake/GCC/OpenOCD对应
```
CMakeLists.txt
```
加OpenOCD
```
.cfg
```
文件。

当本技能可用时，运行

python scripts/check_syscfg.py <project-dir>

。

读取
```
.syscfg
```
元数据：器件、封装、SDK产品、SysConfig版本、模块、实例、引脚、时钟和中断。
检查生成的
```
ti_msp_dl_config.h
```
，获取宏名称、IRQ名称、实例名称以及SysConfig初始化函数的准确拼写。
在添加不熟悉的SysConfig字段前，检查用户现有
```
.syscfg
```
、
```
examples/*/manifest.json
```
、TI SDK示例或
```
source/ti/driverlib/.meta/*.syscfg.js
```
。
修改最小范围的相关
```
.syscfg
```
和应用代码。
默认情况下，先进行最小化的基于证据的
```
.syscfg
```
编辑，再运行
```
python scripts/run_sysconfig.py <project-dir>
```
，之后再重新构建。仅当用户明确要求，或当前会话已确认暴露SysConfig MCP工具时，才使用CCS SysConfig MCP。
如果需要烧录或调试，在选择后端前运行
```
python scripts/detect_probe.py
```
或
```
python scripts/check_syscfg.py <project-dir> --probe
```
。确认配置的调试器与连接的硬件匹配，并且编程后优先选择系统复位。

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.

将
```
.syscfg
```
视为引脚复用、外设配置、时钟、中断、DMA所有权及生成初始化代码的唯一可信源。
优先使用SysConfig + DriverLib进行GPIO、UART、PWM、定时器、ADC、I2C、SPI、DMA和时钟配置。
请勿手动编辑生成的输出文件，例如
```
Debug/ti_msp_dl_config.c
```
、
```
Debug/ti_msp_dl_config.h
```
、Keil布局中项目根目录的
```
ti_msp_dl_config.c
```
/
```
ti_msp_dl_config.h
```
文件对、
```
device_linker.cmd
```
、
```
Objects/
```
、
```
Listings/
```
、目标文件、映射文件或
```
.out
```
文件。

保留

.syscfg

的元数据，例如

@cliArgs

、

@v2CliArgs

、

@versions

、

--device

、

--package

和

--product

。

请勿猜测生成的名称。读取
```
ti_msp_dl_config.h
```
并使用本地宏和本地初始化函数的拼写，例如
```
SYSCFG_DL_init()
```
。
请勿自创SysConfig字段、枚举值、器件元数据、开发板名称、封装名称或工具版本。需根据本地示例、SDK元数据或SysConfig CLI进行验证。
新版SysConfig可能明确推荐使用CCS SysConfig MCP。本技能默认不会探测或要求使用该未经验证的后端：仅当用户要求使用MCP，或当前会话已确认暴露SysConfig MCP工具时才使用。否则，先进行最小化手动编辑，随后立即进行独立CLI验证，并说明此操作无法提供MCP的交互式变更反馈。
保留用户无关的代码、注释、版权头、项目布局及现有
```
.syscfg
```
设置。如果请求的功能需要较大规模的重写，尽可能先解释原因再进行操作。
未经用户确认，请勿更改器件、封装、SDK、编译器、CCS版本、开发板或调试器。
如果用户仅要求“烧录”或“调试”，请勿默认使用J-Link、XDS110、CMSIS-DAP/DAPLink或ST-Link。先探测连接的调试器。如果探测结果未知、连接了多个调试器，或项目配置与物理调试器冲突，请停止操作并询问用户使用哪个后端。
将调试器探测结果为空视为不确定，而非无调试器连接的证明。部分DAPLink/CMSIS-DAP和XDS110设备仅显示为Windows的
```
USBDevice
```
、
```
HIDClass
```
或
```
Ports
```
子设备。检查操作系统的USB/PnP设备和串口（Windows上运行
```
python scripts/serial_console.py --list
```
），然后尝试目标后端的只读探测/列表命令，或在得出无调试器连接的结论前询问用户。
如果SysConfig发出警告，请将其与构建/烧录成功信息分开报告。请勿将产生警告的生成过程称为“干净”。
如果未在连接的开发板上验证硬件行为，请说明验证仅停留在源码、SysConfig或构建阶段。

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.

当用户明确说明开发板为LCKFB Tianmengxing MSPM0G3507时：

除非用户要求使用这些引脚，或本地项目已特意使用，否则避免将A21/PA21、A23/PA23、A02/PA02和A18/PA18分配给普通用户请求的引脚功能。
PA10和PA11也被标记为特殊引脚，但Tianmengxing开发板将其作为默认UART引脚。当为UART选择引脚时，如果PA10（TX）和PA11（RX）空闲且匹配请求的UART实例，优先考虑使用它们。对于GPIO、PWM、SPI、I2C、定时器或其他非UART用途，仍需将PA10/PA11视为特殊引脚，优先选择其他可用引脚。
如果用户要求将这些特殊引脚之一用于非默认用途，请提醒他们Tianmengxing开发板的注意事项。特别要说明，重新配置PA10/PA11可能会与开发板的默认UART连接冲突，甚至导致该连接失效。
请勿擅自将现有项目的引脚从这些特殊引脚移开。先说明开发板的注意事项，再根据用户的意图询问或继续操作。

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.

简单项目通常将大部分逻辑放在
```
main.c
```
、
```
empty.c
```
或少量文件中。在此类文件中进行范围明确的编辑是可接受的。
框架项目通常有多个源目录，例如
```
app/
```
、
```
bsp/
```
、
```
components/
```
、
```
core/
```
、
```
drivers/
```
、
```
hal/
```
、
```
middleware/
```
或
```
tasks/
```
。在添加外设或更改控制逻辑前，先确定所有权边界。
请勿假设所有MSPM0项目都类似CCS项目或单文件结构。框架项目仍可使用CCS、Keil或CMake/GCC/OpenOCD。
对于控制代码，在更改周期或优先级前，确认计时来源是定时器ISR、RTOS任务延迟、硬件PWM/ADC触发链还是主循环轮询。

Keil Project Checks

Keil项目检查

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.

对于将SysConfig输出保存在项目根目录的Keil-based MSPM0项目，将
```
system.syscfg
```
和
```
ti_msp_dl_config.c
```
/
```
ti_msp_dl_config.h
```
视为配置源。
将Keil
```
.uvprojx
```
视为项目入口点，分散加载文件视为链接器的可信源，
```
Objects/
```
、
```
Listings/
```
、
```
*.uvoptx
```
、构建日志和生成的输出文件仅用于检查，除非请求明确针对这些文件。
对于项目的应用代码，遵循其自身的源布局，而非假设CCS的默认布局。

CMake / GCC / OpenOCD Checks

CMake / GCC / OpenOCD检查

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.

将
```
CMakeLists.txt
```
、工具链文件和OpenOCD
```
.cfg
```
文件视为CMake/GCC/OpenOCD项目的入口点。
如果存在现有CMake构建目录，通过该目录进行构建，例如
```
cmake --build cmake-build-debug --target <target>
```
。
MSPM0的OpenOCD烧录通常需要支持TI MSPM0的OpenOCD构建版本或TI扩展分支。如果OpenOCD报告
```
unable to find a matching CMSIS-DAP device
```
，请将其报告为调试器探测失败，而非固件失败。
当活跃项目使用OpenOCD而非DSLite时，无需依赖CCS
```
targetConfigs/*.ccxml
```
。

FreeRTOS Checks

FreeRTOS检查

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.

如果项目中存在
```
FreeRTOSConfig.h
```
、
```
FreeRTOS.h
```
、
```
task.h
```
、
```
xTaskCreate
```
或
```
vTaskStartScheduler
```
，则将该项目视为支持RTOS。
保持RTOS处理轻量化：尊重现有的任务、队列、ISR和阻塞调用边界；除非用户要求，否则不要强加特定的框架架构。

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.

如果用户遗漏了重要的硬件参数，请勿擅自选择有风险的值。

对于低风险默认值，使用本技能的
```
examples/
```
或本地TI SDK示例，然后告知用户使用了哪些默认值。
对于重要参数，在编辑前询问用户，并提供具体建议。
重要的缺失参数包括引脚、外设实例、UART波特率/数据位/奇偶校验/停止位、定时器周期、PWM频率/占空比/极性、ADC通道/参考电压/采样时间、DMA方向/源/目标、中断优先级以及外部模块电源/逻辑电平。

示例：如果用户请求“添加定时器中断”，询问他们想要使用哪个定时器和周期，如果不确定，推荐使用TIMG，周期设为1 ms或10 ms。

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".

当被要求驱动外部模块、传感器、电机驱动器、舵机、显示屏、无线电或自定义开发板时：

如果缺少相关信息，询问用户模块的数据手册、原理图、引脚图、供电电压、逻辑电平、通信协议和关键参数。
在归咎于代码前，验证接线假设：电源、接地、上拉电阻、电平转换、复位/使能引脚、引导引脚、片选、UART TX/RX交叉、I2C地址、SPI模式、PWM极性和共享引脚。
如果多次尝试失败，但SysConfig、构建、烧录和代码逻辑看起来都正确，请明确提出可能是接线、电源、模块模式、数据手册不匹配、硬件损坏或测试流程错误的原因。
将“固件看起来正确”与“硬件已验证正确”区分开。

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.

仅在需要时读取参考资料：

```
references/project_workflows.md
```
：.syscfg编辑、CCS / Keil / CMake项目布局、SDK模式查找、SysConfig CLI、构建、DSLite/J-Link和OpenOCD。
```
references/driverlib_runtime_rules.md
```
：DriverLib使用、中断、时钟树、延迟和常见运行时错误。
```
references/hardware_validation_notes.md
```
：已验证的Tianmengxing MSPM0G3507经验、HFXT警告、烧录/复位行为和实际开发板注意事项。
```
references/debug_backends.md
```
：CCS-DSS和OpenOCD/GDB调试器、烧录、断点、重试和手动解锁工作流。

将

examples/

作为可复用测试模式的来源之一。在打开单个示例文件前，优先使用

scripts/list_examples.py

检查可用示例，但请勿假设打包示例的优先级高于用户现有项目结构或官方TI SDK示例。

Examples

示例规范

Each reusable example should contain:

text

examples/<name>/
├─ example.syscfg
├─ README.md
├─ manifest.json
└─ src/
   └─ source files copied from the minimal relevant project surface

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.

每个可复用示例应包含以下结构：

text

examples/<name>/
├─ example.syscfg
├─ README.md
├─ manifest.json
└─ src/
   └─ source files copied from the minimal relevant project surface

不要求用户将完整CCS项目放入

examples/

。使用

scripts/capture_example.py

从真实项目中提取紧凑的示例包。

将示例应用到用户项目时：

将技能示例视为经过验证的参考，而非强制的项目模板。
仅复制所需的
```
.syscfg
```
字段、生成名称预期、代码模式或调试经验。
保留用户现有的文件布局和命名。如果示例使用
```
BSP/
```
，除非用户要求该结构，或项目已遵循该结构，否则不要在用户项目中创建
```
BSP/
```
。
当用户本地风格与示例的目录名称、包装器名称或分层结构冲突时，优先使用用户的本地风格。
当官方TI SDK示例和本地SDK元数据更匹配用户的开发板、SDK版本、外设或工具链时，将其视为同等或更高优先级。
对于DMA UART示例，为每个UART实例保留独立的TX缓冲区，避免使用共享的静态printf缓冲区，并为每个端口选择合适的RX处理方式：对需要立即行解析的端口使用ISR回调，对额外接收端口使用
```
UART_poll()
```
，对不接收数据的端口仅初始化TX功能。
对于周期性定时器中断，在
```
.syscfg
```
中配置TIMER实例和中断，确认生成的加载值与生成的CPU时钟匹配，在应用代码中启用生成的IRQ，并保持ISR代码简短。

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/OpenOCD clues, build output, target config, and validation hints.
```
python scripts/run_sysconfig.py <project-dir>
```
: discover the project-declared SysConfig and MSPM0 SDK versions, then validate the selected
```
.syscfg
```
into an isolated temporary directory without overwriting project outputs. Use
```
--tool
```
or
```
--product
```
only for an intentional explicit override.
```
python scripts/detect_probe.py
```
: read-only connected-probe detection for common CMSIS-DAP/DAPLink, J-Link, XDS110, and ST-Link hardware; an empty result is explicitly inconclusive and requires OS/backend fallback checks.
```
python scripts/check_syscfg.py <project-dir> --probe
```
: run the static check, detect connected probes, compare them with project hints, and suppress unsafe flash suggestions when a CCS
```
.ccxml
```
conflicts with the physical probe.

python scripts/list_examples.py

: list packaged examples from

examples/*/manifest.json

python scripts/capture_example.py <project-dir> --name <example-name> --include <glob>

: package selected source files and

.syscfg

from a user project into

examples/<example-name>/

python scripts/index_syscfg_examples.py <mspm0-sdk-root> --board LP_MSPM0G3507 --module UART

: search local TI SDK examples and module metadata.

```
python scripts/serial_console.py --list
```
: list serial ports.
```
python scripts/ccs_dss_debug.py <project-dir> probe --leave-running
```
: connect through CCS Debug Server Scripting, read reset/register state, verify the configured
```
.ccxml
```
debug path, and continue the target before disconnecting.

python scripts/ccs_dss_debug.py <project-dir> load-symbols --symbol main

: load debug symbols from

.out

without programming flash.

```
python scripts/openocd_debug.py <project-dir> probe
```
: connect through OpenOCD, halt briefly, report target state, and resume.
```
python scripts/openocd_debug.py <project-dir> flash
```
: flash, verify, and reset-run an auto-detected
```
.out
```
,
```
.elf
```
,
```
.axf
```
, or
```
.hex
```
output through OpenOCD.

python scripts/openocd_debug.py <project-dir> run-to-symbol --symbol main

: use OpenOCD +

arm-none-eabi-gdb

to reset and run to a symbol breakpoint.

For the verified CH340 setup, use

python scripts/serial_console.py -p COM6 -b 115200 --timestamp --duration 10

after closing other serial tools such as VOFA+. For line-based MCU parsers, send one test frame and wait for the echo with

python scripts/serial_console.py -p COM6 -b 115200 --send "ping" --send-line --timestamp --duration 3

. Use

--send-hex "00 00 80 3F"

when testing binary payloads.

使用Python 3.10或更高版本运行捆绑脚本。

serial_console.py

还需要

pyserial

；如果导入失败，请告知用户运行

python -m pip install pyserial

。TI SDK、SysConfig、CCS/UniFlash、OpenOCD和GDB仍是外部工作流依赖项，本技能不会安装它们。

```
python scripts/check_syscfg.py <project-dir>
```
：对.syscfg、生成文件、引脚、初始化函数拼写、项目结构、CCS/Keil/CMake/OpenOCD线索、构建输出、目标配置和验证提示进行静态项目检查。
```
python scripts/run_sysconfig.py <project-dir>
```
：发现项目声明的SysConfig和MSPM0 SDK版本，然后将选定的.syscfg验证到独立的临时目录中，不会覆盖项目输出。仅在有意显式覆盖时使用
```
--tool
```
或
```
--product
```
参数。
```
python scripts/detect_probe.py
```
：对常见的CMSIS-DAP/DAPLink、J-Link、XDS110和ST-Link硬件进行只读连接探测；结果为空明确表示不确定，需要进行操作系统/后端回退检查。
```
python scripts/check_syscfg.py <project-dir> --probe
```
：运行静态检查、探测连接的调试器、将其与项目提示进行比较，并在CCS
```
.ccxml
```
与物理调试器冲突时抑制不安全的烧录建议。

python scripts/list_examples.py

：从

examples/*/manifest.json

中列出打包的示例。

python scripts/capture_example.py <project-dir> --name <example-name> --include <glob>

：将用户项目中选定的源文件和.syscfg打包到

examples/<example-name>/

中。

python scripts/index_syscfg_examples.py <mspm0-sdk-root> --board LP_MSPM0G3507 --module UART

：搜索本地TI SDK示例和模块元数据。

```
python scripts/serial_console.py --list
```
：列出串口。
```
python scripts/ccs_dss_debug.py <project-dir> probe --leave-running
```
：通过CCS Debug Server Scripting连接，读取复位/寄存器状态，验证配置的.ccxml调试路径，并在断开连接前继续运行目标设备。

python scripts/ccs_dss_debug.py <project-dir> load-symbols --symbol main

：从.out文件加载调试符号，无需编程烧录闪存。

```
python scripts/openocd_debug.py <project-dir> probe
```
：通过OpenOCD连接，短暂暂停，报告目标状态，然后恢复运行。
```
python scripts/openocd_debug.py <project-dir> flash
```
：通过OpenOCD烧录、验证并复位运行自动检测到的.out、.elf、.axf或.hex输出文件。

python scripts/openocd_debug.py <project-dir> run-to-symbol --symbol main

：使用OpenOCD +

arm-none-eabi-gdb

复位并运行到符号断点。

对于已验证的CH340设置，关闭其他串口工具（如VOFA+）后，运行

python scripts/serial_console.py -p COM6 -b 115200 --timestamp --duration 10

。对于基于行的MCU解析器，发送一个测试帧并等待回显，运行

python scripts/serial_console.py -p COM6 -b 115200 --send "ping" --send-line --timestamp --duration 3

。测试二进制负载时使用

--send-hex "00 00 80 3F"

。

Flash Backends

烧录后端选择

Before selecting a flash backend for a vague request such as "flash this project", run:

text

python scripts/detect_probe.py
python scripts/check_syscfg.py <project-dir> --probe

Probe detection is read-only. Do not flash when multiple probes are connected, detection is unknown, or the physical probe conflicts with the project configuration until the user confirms the intended backend. On Windows, if no probe is identified, inspect

Get-PnpDevice -PresentOnly

and

python scripts/serial_console.py --list

; a debug probe may expose a CMSIS-DAP/XDS interface or virtual COM port outside the generic USB device class.

The verified CCS flash path is DSLite / UniFlash with J-Link. For automated flashing after clock-tree changes, prefer DSLite System Reset:

text

dslite -c <target.ccxml> -e -r 2 -u <project.out>

For CMake/GCC/OpenOCD projects, use the project's existing flash target or explicit OpenOCD config. The packaged

openocd_debug.py

helper can also flash an existing compatible output. Keep the backend explicit and report probe-discovery errors separately from build success.

对于诸如“烧录此项目”之类的模糊请求，选择烧录后端前先运行：

text

python scripts/detect_probe.py
python scripts/check_syscfg.py <project-dir> --probe

调试器探测是只读操作。当连接多个调试器、探测结果未知或物理调试器与项目配置冲突时，请勿进行烧录，直到用户确认目标后端。在Windows上，如果未识别到调试器，检查

Get-PnpDevice -PresentOnly

和

python scripts/serial_console.py --list

；调试器可能在通用USB设备类之外暴露CMSIS-DAP/XDS接口或虚拟串口。

已验证的CCS烧录路径是使用J-Link的DSLite / UniFlash。对于时钟树更改后的自动化烧录，优先使用DSLite系统复位：

text

dslite -c <target.ccxml> -e -r 2 -u <project.out>

对于CMake/GCC/OpenOCD项目，使用项目现有的烧录目标或明确的OpenOCD配置。打包的

openocd_debug.py

助手也可以烧录现有的兼容输出文件。保持后端明确，并将调试器探测错误与构建成功信息分开报告。

Debug Backends

调试后端选择

Keep CCS-DSS and OpenOCD/GDB as separate backends. Read

references/debug_backends.md

before debugging or diagnosing repeated probe failures.

For CCS / CCS Theia / UniFlash-style projects with a matching

targetConfigs/*.ccxml

text

python scripts/ccs_dss_debug.py <project-dir> probe --leave-running

For OpenOCD-capable MSPM0 projects:

text

python scripts/openocd_debug.py <project-dir> probe

The CCS-DSS physical probe is selected by

.ccxml

; it is not inherently J-Link-only. Use symbol-only loading when firmware is already flashed and rewriting flash is unnecessary. For OpenOCD, do not run concurrent operations against one probe. Neither backend should silently issue destructive recovery. If the target appears locked or protected, stop and ask the user to perform their manual unlock procedure. Debug actions can halt the CPU, so report that risk before using breakpoints or register inspection on real-time control hardware.

将CCS-DSS和OpenOCD/GDB视为独立后端。进行调试或诊断重复调试器失败前，请先阅读

references/debug_backends.md

。

对于具有匹配

targetConfigs/*.ccxml

的CCS / CCS Theia / UniFlash风格项目：

text

python scripts/ccs_dss_debug.py <project-dir> probe --leave-running

对于支持OpenOCD的MSPM0项目：

text

python scripts/openocd_debug.py <project-dir> probe

CCS-DSS物理调试器由

.ccxml

选择；它并非仅支持J-Link。当固件已烧录且无需重写闪存时，使用仅加载符号的方式。对于OpenOCD，请勿对同一个调试器运行并发操作。两个后端都不应静默执行破坏性恢复操作。如果目标设备显示锁定或受保护，请停止操作并要求用户执行手动解锁流程。调试操作可能会暂停CPU，因此在对实时控制硬件使用断点或寄存器检查前，请告知用户此风险。",