組込みデバッグとトレースの基礎

JTAG は複数信号（TCK/TMS/TDI/TDO、任意で TRST）を使う従来からの方式で、デイジーチェーン接続に対応します。SWD は Arm が定義した2線式（SWCLK/SWDIO）で、ピン数を節約できるため小型基板で広く使われます。cJTAG は2線で JTAG 相当の機能を提供します。

選定時は、コネクタ形状（10/20ピン、Cortex Debug、車載向けの独自コネクタ）、ターゲット電圧レンジ、そしてリセット信号の扱いを確認してください。「対応コアに載っている」だけでは接続できないことがあります。

ハードウェアトレースは、CPU の実行情報を専用ポートから非侵襲で吐き出す方式です。Arm の ETM/ITM、Infineon の MCDS、Power Architecture 系の NEXUS などがこれにあたります。実行そのものに影響を与えないため、タイミングを証拠として残す用途に適します。

ただし、基板側にトレースポートが引き出されていなければ使えません。後からプローブだけを買い足しても、ハードウェアが対応していなければ意味がない、というのがこの分野で最も多い後悔です。トレースの要否は基板設計時に決めてください。

ソフトウェアトレースは、RTOS やアプリケーションに記録コードを組み込む方式です。既存ハードのまま導入できる代わりに、記録のオーバーヘッドと計装の設計が必要になります。タスク切り替え・割込み・同期プリミティブの挙動を追うには十分実用的です。

ハードウェアトレースには、プローブ内蔵バッファに貯める方式と、ホストへ連続転送するストリーミング方式があります。

内蔵バッファは、容量分の時間しか記録できません。「まれにしか起きない現象」を捕まえるには、ストリーミング対応か、トリガ条件で狙い撃ちできるかが重要になります。

必要なトレース帯域は、コア数・クロック・分岐密度で決まります。多コアの同時トレースでは、出力帯域がボトルネックになることがあります。

マルチコア SoC では、あるコアで止めた瞬間に他のコアが走り続けると、システム全体の状態が変わってしまい、原因究明ができません。コア間の同期停止（cross-triggering）に対応した機器かどうかを確認してください。

車載の AURIX や複数 SoC 構成では、「どのコアで何が起きていたか」を同一時間軸で見られることが前提になります。ここが担保できないと、タイミング起因の不具合は事実上追えません。

台数を並べて自動実行するなら、USB より Ethernet／PoE 対応機のほうが運用が安定します。USB は台数が増えるとエニュメレーションと給電が問題になりやすいためです。

スクリプト API（Python など）の有無も確認してください。単体テストの自動実行、カバレッジ取得、実行時間の回帰監視まで含めるなら、GUI 操作ではなく API で制御できることが前提になります。

ISO 26262 の ASIL C/D では、CPU 余裕度（実行時間の最悪値に対する余裕）を示すことが求められる場面があります。

計装によるオーバーヘッドが許容されない場合、非侵襲のハードウェアトレースで実測を取るのが確実です。この要求が出る可能性があるなら、基板設計の段階でトレースポートを確保しておいてください。