命令トレース（実行トレース）でマイコンの不具合解析を劇的に効率化する方法

組込みソフトウェアの開発において、「たまにしか発生しない変数の不正書き換え」や「原因不明のハードフォルト（HardFault）」に頭を悩まされた経験はありませんか？

これらのデバッグや動作解析を劇的に効率化してくれるのが「実行トレース（命令トレース）」機能です。実行トレースは非常に強力な機能を持ちながら、実は開発現場であまり活用されていません。

本記事では、Cortex-Mマイコンにおけるトレース機能の種類や、不具合解析を効率化する4つの具体的なユースケース、そして開発現場でトレースを導入するためのハードルを越えるポイントを分かりやすく解説します。

Cortex-Mマイコンにおける3つのトレース機能

Cortex-Mアーキテクチャでは、主に以下の3つのトレース機能（およびデバッグ手法）が提供されています。目的や利用可能なピン数に応じて使い分けることが重要です。

【Tips】ITMを用いた低オーバーヘッドのprintfデバッグ

従来の printf 関数によるログ出力は、実機ボードで確認したところ1回につき約800 CPUサイクルという非常に重い処理（実行オーバーヘッド）が発生していました。

これに対し、Cortex-MのITM（インストルメンテーション・トレース・マクロセル）機能を利用すると、わずか 19〜26 CPUサイクル で変数の値やPC（プログラムカウンタ）の値をSWOピンから出力できます。プログラムの実行タイミングを大きく崩さずに値を観測したい場合に最適です。

不具合解析を劇的にラクにする！4つのトレース活用ユースケース

実行トレースは、ただログを眺めるだけではなく、デバッガのブレイクポイント機能と組み合わせることで真価を発揮します。代表的な4つのユースケースをご紹介します。

① 原因不明の「変数の不正書き換え」を特定する

「誰かが変数の値を書き換えているが、ソースコードのどこで発生しているか分からない」というケースです。

• 解決法:
• トレースのメリット:

対象の変数に対して「データブレイク（Writeアクセス）」を設定します。さらに、特定の値（例: 0x30）が書き込まれた時だけ止めたい場合は、データ照合条件を有効にします。

書き込みが発生した瞬間にブレイクが微進して停止します。そこからトレース履歴を下から上（過去方向）に遡ることで、実際に不正な書き込みを行った命令（Store命令など）とソースコードの該当箇所をピンポイントで特定できます。

② 年中発生する「ハードフォルト（HardFault）」の要因特定

ハードフォルトが発生すると、通常は HardFault_Handler にジャンプして停止しますが、停止した時点では「すでに異常が起きた後」であるため、直前に何が起きていたかが分かりません。

• 解決法:
• トレースのメリット:

HardFault_Handler にコードブレイクを設定してプログラムを実行します。

ブレイクした瞬間、マイコン（またはデバッガ）のメモリ内にはフォルトが発生する直前の実行命令履歴がすべて残っています。履歴を遡ることで、「アドレスの指定ミスによる不正なI/Oアクセス（BusFault）」といった原因を、ソースコードと突き合わせながら一目で特定できます。

③ 「たまに遅くなる関数」の実行阻害要因を検出する

特定の関数（例: F5）の処理が、時々異常に遅くなるというパフォーマンスのバグです。

• 解決法:
• トレースのメリット:

関数の入り口に「トレース開始」、出口に「トレース停止」のトリガー（ブレイクポイント）を設定し、特定の関数内だけトレースを取得するようにします。

無駄なログを省き、対象関数が実行されたログだけを集中して確認できます。正常時と異常時のログを比較することで、「関数 F5 の実行中に、特定の割り込みハンドラが予期せず介入していた」といった実行阻害の要因を明確に可視化できます。

④ 実機テストにおける「実行箇所の確認（カバレッジ）」

単体テストとは異なり、実機に近い環境で行うテストでは、どのコードが実際に動いたか（網羅率）を把握するのが困難です。

• 解決法:
• トレースのメリット:

大容量の ETMトレース を活用して、実機テスト実行中の全ログを取得します。

EWARM（IAR Embedded Workbench）などのツール上で、どの関数やどの分岐命令が実行されたかを一元管理でき、実機テストにおけるテスト不足（カバレッジの漏れ）を視覚的に確認できます。

現場でトレースを活用するための4つの実践ポイント

「トレースは便利そうだけど、ピンが足りない、コストが見合わない」という課題を解決するためのヒントです。

1) まずは「オンチップメモリートレース」が付いているかマニュアルを確認

高価な専用デバッガ（I-jet Trace）がなくても、最近の多くのマイコンには、チップ内部にトレース用メモリ（MTB、ETB、ETFなど）が標準搭載されているものがあります。

これらは、標準的なデバッガ（I-jetなど）と通常のデバッグ接続（JTAG/SWD）さえあれば、今すぐ無料で利用可能です。利用しない手はありません。まずは製品マニュアルを確認してみましょう。

2) ETMトレースは最小「2ピン」でも出力可能

通常、ETMトレースではクロック信号に加えて最大4ビット程度のデータ線（TRACECLK＋TRACEDATA[0..3]）を使用し、合計5ピン前後のピンリソースを消費します。

ただし、デバッカやツールの設定によってデータ線の本数を削減することも可能で、例えば1ビット構成（クロック＋データ1本）とすることでピン数を抑えた運用も行えます。
その場合は帯域が制限されるため、トレースデータの欠損リスクが増える点に注意が必要です。

アイデア: 開発中は、量産品でパワーLED点灯用などに割り当てているピンを一時的にトレースピンとしてアサインし、デバッグ効率を最優先する設計にするのも一つの手法です。

3) マイコン選定時に「デバッグ機能」を考慮する

量産コストや周辺機能（ペリフェラル）だけでマイコンを選んでしまうと、Cortex-M0/M0+のようにアーキテクチャ自体にSWOピンが実装されていないモデルを選んでしまい、後から効率的なデバッグができなくなることがあります。開発フェーズのデバッグ工数を削減するためにも、デバッグ機能の有無を選定基準に含めることが重要です。

4) 「開発用」と「量産用」でマイコン（グレード）を使い分ける

量産コストを抑えるために、1円でも安いマイコンを選ばなければならないケースは多々あります。その場合の推奨アプローチが、「基板やパッケージ、ピン互換性を維持したまま、開発・評価ボードにだけ上位グレードのマイコンを載せる」という手法です。

• 例（TI社 mspm0シリーズの場合）:
  • 量産用ボード: コストの安い Lシリーズ（オンチップトレース非搭載）
  • 開発・解析用ボード: ピン互換があり、MTB（オンチップトレース）を搭載した Gシリーズ

このように使い分けることで、量産コストを抑えつつ、開発や市場不具合の解析時にはトレース機能をフル活用して迅速にバグを退治できる環境を構築できます。

まとめ：トレースは「過去の動き」を教えてくれるタイムマシン

不具合が発生した際、「エラーが出た場所」は分かっても、「その前に何をしていたか」が分からなければ原因究明には至りません。実行トレースは、まさにマイコンの過去の動きを知ることができるタイムマシンです。

• オンチップトレースが載っているマイコンなら、使わないと損です。
• ETMトレース（I-jet Trace）を活用すれば、大規模なバグや実機テストの検証が圧倒的にスムーズになります。

ぜひ、次回のマイコン選定やデバッグ環境構築の参考にしてください。