mspm0-ccs

MSPM0 エージェントスキル

SysConfig と DriverLib を使用する TI MSPM0 ファームウェアプロジェクトで、CCS／CCS Theia、Keil/uVision、または CMake + Arm GNU Toolchain + OpenOCD のワークフローを利用する場合に、このスキルを使用してください。Claude Code、OpenCode、OpenClaw、Continue、Cursor、Codex などの CLI／エディターエージェントを対象としています。

デフォルトのワークフロー

1. プロジェクトの .syscfg または system.syscfg、編集可能なソースファイル、生成された ti_msp_dl_config.h、および有効なプロジェクトエントリーポイントを特定します。CCS の場合は targetConfigs/*.ccxml、Keil/uVision の場合は *.uvprojx とスキャッターファイル、CMake/GCC/OpenOCD の場合は CMakeLists.txt と OpenOCD の .cfg ファイルです。
2. このスキルが利用可能な場合は、python scripts/check_syscfg.py <project-dir> を実行します。
3. .syscfg のメタデータを読み取ります。デバイス、パッケージ、SDK 製品、SysConfig のバージョン、モジュール、インスタンス、ピン、クロック、割り込みを確認します。
4. 生成された ti_msp_dl_config.h を調べ、マクロ名、IRQ 名、インスタンス名、SysConfig 初期化関数の正確な表記を確認します。
5. 不慣れな SysConfig フィールドを追加する前に、ユーザーの既存の .syscfg、examples/*/manifest.json、TI SDK のサンプル、または source/ti/driverlib/.meta/*.syscfg.js を確認します。
6. 関連する .syscfg とアプリケーションコードの変更範囲を最小限に抑えます。
7. デフォルトでは、根拠に基づいて .syscfg を最小限変更し、再ビルドの前に python scripts/run_sysconfig.py <project-dir> を実行します。ユーザーが明示的に要求した場合、または現在のセッションですでに確認済みの SysConfig MCP ツールが利用できる場合に限り、CCS SysConfig MCP を使用します。
8. 書き込みやデバッグを行う場合は、バックエンドを選択する前に python scripts/detect_probe.py または python scripts/check_syscfg.py <project-dir> --probe を実行します。設定されたプローブが接続済みのハードウェアに適合していることを確認し、書き込み後は System Reset を優先します。

コアルール

• ピンマルチプレクサ、周辺機器の設定、クロック、割り込み、DMA の所有権、生成される初期化コードについては、.syscfg を唯一の信頼できる情報源として扱ってください。
• GPIO、UART、PWM、Timer、ADC、I2C、SPI、DMA、クロックの設定には、SysConfig と DriverLib を優先してください。
• 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 ファイルなどの生成物を手動で編集しないでください。
• @cliArgs、@v2CliArgs、@versions、--device、--package、--product などの .syscfg メタデータを保持してください。
• 生成される名前を推測しないでください。ti_msp_dl_config.h を読み、SYSCFG_DL_init() のように、ローカルのマクロとローカルの初期化関数の綴りを使用してください。
• SysConfig のフィールド、列挙値、デバイスのメタデータ、ボード名、パッケージ名、ツールのバージョンを捏造しないでください。ローカルの例、SDK メタデータ、または SysConfig CLI で検証してください。
• 新しい SysConfig リリースでは、CCS SysConfig MCP が明示的に推奨されることがあります。このスキルでは、未検証のバックエンドをデフォルトで調査したり必須にしたりしません。ユーザーが MCP を求めている場合、または現在のセッションで確認済みの SysConfig MCP ツールがすでに利用可能な場合にのみ使用してください。それ以外の場合は、最小限の手動編集を行ってから、直ちにスタンドアロン CLI で検証し、MCP の対話的な変更フィードバックは得られないことを伝えてください。
• 関係のないユーザーコード、コメント、著作権表示、プロジェクトレイアウト、既存の .syscfg 設定を保持してください。要求された機能に大規模な書き換えが必要な場合は、可能であれば変更を行う前にその理由を説明してください。
• ユーザーの確認なしに、デバイス、パッケージ、SDK、コンパイラ、CCS のバージョン、ボード、デバッグプローブを変更しないでください。
• ユーザーが「flash」または「debug」とだけ依頼した場合、J-Link、XDS110、CMSIS-DAP/DAPLink、ST-Link のいずれかを勝手に想定しないでください。まず接続されているプローブを検出してください。検出結果が不明な場合、複数のプローブが接続されている場合、またはプロジェクト設定と実際のプローブが一致しない場合は、作業を止め、使用するバックエンドをユーザーに確認してください。
• プローブ検出結果が空でも、接続されているプローブがないとは限らず、結論は出せません。一部の DAPLink/CMSIS-DAP および XDS110 デバイスは、Windows の USBDevice、HIDClass、または Ports の子デバイスとしてのみ表示されます。OS の USB/PnP デバイスとシリアルポート（Windows では python scripts/serial_console.py --list）を確認し、その後、使用予定のバックエンドの読み取り専用プローブ／一覧表示コマンドを試すか、プローブが存在しないと判断する前にユーザーに確認してください。
• SysConfig が警告を出力した場合は、ビルド／書き込みの成功とは分けて報告してください。警告が出た生成処理を「クリーン」と表現しないでください。
• 接続されたボードでハードウェアの動作を検証していない場合は、検証がソース、SysConfig、またはビルドの段階までであることを明記してください。

ボード固有のピンに関する注意

ユーザーがボードを LCKFB Tianmengxing MSPM0G3507 と明示した場合：

• ユーザーがそれらのピンを指定した場合、またはローカルのプロジェクトですでに意図的に使用している場合を除き、通常のユーザー依頼によるピン割り当てでは A21/PA21、A23/PA23、A02/PA02、A18/PA18 の使用を避けてください。
• PA10 と PA11 も特殊なピンとして指定されていますが、Tianmengxing ではデフォルトの UART ピンとして配線されています。UART 用のピンを選ぶ際は、空いており、要求された UART インスタンスに適合するなら、まず PA10 TX と PA11 RX を検討してください。GPIO、PWM、SPI、I2C、タイマー、その他 UART 以外の用途では、引き続き PA10/PA11 を特殊なピンとして扱い、他の利用可能なピンを優先してください。
• ユーザーがこれらの特殊なピンをデフォルト以外の用途で駆動または再利用するよう求めた場合は、Tianmengxing ボードに関する注意事項を伝えてください。特に、PA10/PA11 の用途を変更すると、ボードのデフォルト UART 接続と競合するか、その接続が使えなくなる可能性があることを説明してください。
• 既存のプロジェクトでこれらのピンが使用されている場合、ユーザーに知らせずに別のピンへ移さないでください。まずボード固有の注意点を説明し、その後、ユーザーの意図に従って確認するか作業を進めてください。

プロジェクト構成の確認

• シンプルなプロジェクトでは、通常、ロジックの大部分が main.c、empty.c、または少数のファイルにまとめられています。対象を絞った編集であれば、これらのファイルを変更しても問題ありません。
• フレームワークを使用するプロジェクトには、app/、bsp/、components/、core/、drivers/、hal/、middleware/、tasks/ など、複数のソースディレクトリがあることがよくあります。ペリフェラルを追加したり制御ロジックを変更したりする前に、まず各領域の責任範囲を確認してください。
• すべての MSPM0 プロジェクトが CCS のような構成、または単一ファイル構成だと考えないでください。フレームワークを使用するプロジェクトでも、CCS、Keil、CMake/GCC/OpenOCD を使用している場合があります。
• 制御コードを変更する場合、周期や優先度を変更する前に、タイミングがタイマー ISR、RTOS タスクの遅延、ハードウェア PWM/ADC のトリガーチェーン、またはメインループのポーリングのどれに由来するかを確認してください。

Keil プロジェクトの確認

• プロジェクトのルートに SysConfig の出力を配置する Keil ベースの MSPM0 プロジェクトでは、system.syscfg と ti_msp_dl_config.c / ti_msp_dl_config.h を設定のソースとして扱ってください。
• Keil の .uvprojx をプロジェクトのエントリーポイントとして、scatter ファイルをリンカー設定の信頼できる情報源として扱ってください。依頼で明示的に対象となっていない限り、Objects/、Listings/、*.uvoptx、ビルドログ、生成された出力は確認専用としてください。
• プロジェクトのアプリケーションコードについては、CCS の既定の構成を想定せず、プロジェクト独自のソースレイアウトに従ってください。

CMake / GCC / OpenOCD の確認

• CMake/GCC/OpenOCD プロジェクトでは、CMakeLists.txt、ツールチェーンファイル、OpenOCD の .cfg ファイルをプロジェクトのエントリーポイントとして扱ってください。
• 既存の CMake ビルドディレクトリがある場合は、そこからビルドしてください。例：cmake --build cmake-build-debug --target <target>。
• MSPM0 の OpenOCD による書き込みには通常、TI MSPM0 対応の OpenOCD ビルド、または TI の拡張ブランチが必要です。OpenOCD が unable to find a matching CMSIS-DAP device を報告した場合は、ファームウェアの問題ではなく、プローブの検出失敗として報告してください。
• アクティブなプロジェクトが DSLite ではなく OpenOCD を使用している場合、CCS の targetConfigs/*.ccxml は必須としないでください。

FreeRTOS の確認

• FreeRTOSConfig.h、FreeRTOS.h、task.h、xTaskCreate、または vTaskStartScheduler が存在する場合は、そのプロジェクトが RTOS に対応しているものとして扱ってください。
• RTOS の扱いは軽量に保ってください。既存のタスク、キュー、ISR、ブロッキング呼び出しの境界を尊重し、ユーザーから求められない限り、特定のフレームワークアーキテクチャを押し付けないでください。

曖昧な依頼

ユーザーが重要なハードウェアパラメーターを指定していない場合、リスクのある値を暗黙に選ばないでください。

• リスクの低い既定値については、このスキルの examples/ またはローカルの TI SDK の例を参照し、適用した既定値をユーザーに伝えてください。
• 重要なパラメーターについては、編集前に確認し、具体的な推奨値を提示してください。
• 指定がないと重要なパラメーターには、ピン、ペリフェラルのインスタンス、UART のボーレート／データビット／パリティ／ストップビット、タイマー周期、PWM 周波数／デューティ比／極性、ADC チャンネル／基準電圧／サンプル時間、DMA の方向／ソース／宛先、割り込み優先度、外部モジュールの電源／ロジックレベルが含まれます。

例：ユーザーから「タイマー割り込みを追加して」と依頼された場合、使用するタイマーと周期を確認し、決めかねているようであれば、TIMG の 1 ms または 10 ms などを初期値として推奨してください。

外部モジュールとハードウェアのデバッグ

外部モジュール、センサー、モータードライバー、サーボ、ディスプレイ、無線機器、またはカスタムボードを駆動するよう依頼された場合：

• 入手できていない場合は、モジュールのデータシート、回路図、ピン配置、電源電圧、ロジックレベル、通信プロトコル、主要なパラメーターを尋ねてください。
• コードを問題視する前に、配線に関する前提を検証してください。電源、グラウンド、プルアップ、レベル変換、リセット／イネーブルピン、ブートピン、チップセレクト、UART の TX/RX の交差接続、I2C アドレス、SPI モード、PWM の極性、共有ピンを確認してください。
• SysConfig、ビルド、書き込み、コードロジックに問題がないように見えても、何度試しても失敗する場合は、配線、電源、モジュールのモード、データシートとの不一致、ハードウェアの損傷、またはテスト手順の誤りの可能性を明確に伝えてください。
• 「ファームウェアは正しく見える」ことと「ハードウェアが正しいと確認できた」ことを区別してください。

参考資料の選択

必要な場合にのみ、参考資料を読みます。

• 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：検証済みの天梦星 MSPM0G3507 の知見、HFXT に関する警告、フラッシュ／リセットの動作、実機に関する注意点。
• references/debug_backends.md：CCS-DSS と OpenOCD／GDB のプローブ、フラッシュ、ブレークポイント、再試行、手動ロック解除のワークフロー。

examples/ は、再利用可能なテスト済みパターンの参照元のひとつとして使用します。個別のサンプルファイルを開く前に、scripts/list_examples.py で利用可能なサンプルを確認することを推奨します。ただし、パッケージ化されたサンプルが、ユーザーの既存のプロジェクト構成や公式 TI SDK のサンプルより優先されるとは限りません。

サンプル

再利用可能な各サンプルには、次の内容を含めてください。

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/ を作成しないでください。
• ディレクトリ名、ラッパー名、レイヤー構成がサンプルと異なる場合、ユーザー側の既存スタイルを優先します。
• ユーザーのボード、SDK バージョン、ペリフェラル、ツールチェーンにより適している場合は、公式 TI SDK のサンプルとローカル SDK のメタデータを同等以上に優先します。
• DMA UART のサンプルでは、UART インスタンスごとに TX バッファーを保持し、共有の static な printf バッファーを避け、ポートごとに RX の処理方法を選択します。即時の行解析が必要な 1 つのポートには ISR コールバックを使用し、追加の受信ポートには UART_poll() を使用するか、受信しないポートは TX のみを初期化します。
• 周期タイマー割り込みでは、.syscfg で TIMER インスタンスと割り込みを設定し、生成されたロード値が生成された CPU クロックと一致することを確認して、アプリケーションコードで生成済みの IRQ を有効にし、ISR を短く保ちます。

ツール

同梱スクリプトの実行には 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 ハードウェアを対象とした、接続プローブの読み取り専用検出です。結果が空でも明確な判定とはみなされません。その場合は、OS やバックエンドによる代替チェックが必要です。
• 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 パーサーでは、テストフレームを 1 つ送信し、エコーを待つために python scripts/serial_console.py -p COM6 -b 115200 --send "ping" --send-line --timestamp --duration 3 を使用してください。バイナリペイロードのテストには、--send-hex "00 00 80 3F" を使用してください。

フラッシュのバックエンド

「このプロジェクトを書き込んで」など、曖昧な依頼に対してフラッシュのバックエンドを選択する前に、次を実行してください。

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 インターフェースや仮想 COM ポートを公開していることがあります。

検証済みの CCS フラッシュ経路は、J-Link を使用する DSLite / UniFlash です。クロックツリーを変更した後に自動でフラッシュする場合は、DSLite System Reset を優先してください。

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

CMake/GCC/OpenOCD プロジェクトでは、プロジェクトに既存のフラッシュターゲット、または明示的な OpenOCD 設定を使用してください。同梱の openocd_debug.py ヘルパーでも、既存の互換性がある出力を書き込めます。バックエンドは明示し、プローブの検出エラーはビルドの成功とは分けて報告してください。

デバッグバックエンド

CCS-DSS と OpenOCD/GDB は別々のバックエンドとして扱います。デバッグやプローブ障害の繰り返しの診断を行う前に、references/debug_backends.md を読んでください。

targetConfigs/*.ccxml が一致する CCS ／ CCS Theia ／ UniFlash 形式のプロジェクトの場合：

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

OpenOCD に対応した MSPM0 プロジェクトの場合：

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

CCS-DSS の物理プローブは .ccxml で選択されます。J-Link 専用というわけではありません。ファームウェアがすでに書き込まれていて、フラッシュの再書き込みが不要な場合は、シンボルのみを読み込みます。OpenOCD では、1 つのプローブに対して並行して処理を実行しないでください。どちらのバックエンドも、破壊的な復旧処理を暗黙に実行してはなりません。ターゲットがロックされている、または保護されているように見える場合は、まずプローブ／配線／リセットの障害、アプリケーションの起動障害、SWD パスワードまたはセキュリティポリシー、無効な NONMAIN 構成、フラッシュ書き込み中断後の復旧状態を切り分けてください。天梦星 MSPM0G3507 では、読み取り可能な SWD DPIDR の後に Could not find MEM-AP to control the core エラーが繰り返し発生する状態が、プログラミングの中断後に再現されました。これをプローブが存在しない証拠とみなすのではなく、references/debug_backends.md に記載された UART BSL の復旧範囲に従ってください。一致する XDS ターゲット構成で CCS-DSS を使用する場合、Cortex-M0+ セッションが接続できなくても、読み取り専用の CFGAP_BOOTDIAG チェックは動作することがあります。BSL Mass Erase、DSSM Mass Erase、または Factory Reset は、ユーザーがデータ損失を明示的に承認した場合に限り、references/debug_backends.md に従って実行してください。リセットパルスやタイムアウトしたコマンドから成功を推測してはなりません。デバッグ操作によって CPU が停止する可能性があるため、リアルタイム制御ハードウェアでブレークポイントやレジスターの検査を使用する前に、そのリスクを伝えてください。