5.1クロス開発環境

組込み開発では、ターゲットとなるマイコンボード上で直接コンパイラを動かすことは現実的ではありません。開発者はPC等のホスト上で開発環境を動かし、ターゲット向けの実行コードを生成し、それをターゲットのメモリ配置に合わせて配置し、最後にターゲット実機上で「ソースコード通りに動いているか」を直接観測する必要があります。この節では、その一連の流れを支えるツール群の役割分担と、実機デバッグの現場でどのツールを選ぶかという判断力を養います。

5.1.1クロスコンパイラ・リンカ・ロケータ

• クロスコンパイラ＝開発を行うホスト（PC等・x86系が多い）上で動作しながら、ターゲット（組込みボード・ARM Cortex-M等）向けの機械語を生成するコンパイラ。ホストとターゲットのCPUアーキテクチャが異なるために必要になる。
• リンカ＝コンパイル済みの複数のオブジェクトファイルとライブラリを結合し、1つの実行可能ファイルにまとめるツール。ロケータ＝リンクされたコードやデータを、ターゲットの実際のメモリマップ（Flash開始アドレス・RAM開始アドレス等）上の具体的な番地に配置する処理。組込みではロケータが生成するマップファイルを確認し、コードサイズやデータ配置がターゲットのメモリ容量に収まっているかを検証するのが定石。

5.1.2実機デバッグツール（ICE／JTAG／SWD／エミュレータ）

• ICE（In-Circuit Emulator）＝ターゲットCPUを模擬する専用ハードウェアに置き換え、内部レジスタやバスの状態をリアルタイムに観測・制御できる高機能な実機デバッグ装置。高価だが、実CPUでは見えない内部状態まで追跡できる。
• JTAG（Joint Test Action Group）＝境界走査（バウンダリスキャン）を起源とする標準規格で、専用ピンを介してターゲットCPUに直接アクセスし、ブレークポイント設定・レジスタ/メモリ読み書き・フラッシュ書き込みを行う。現在最も普及したデバッグインタフェース。SWD（Serial Wire Debug）＝ARM系マイコンで使われるJTAGよりピン数が少ない（2本）代替インタフェースで、基板の実装面積やコネクタ数を節約したい小型組込み機器に向く。
• エミュレータ（広義）＝ターゲット実機を使わずソフトウェア的にCPUや周辺回路の動作を模擬する環境。実機の入手前や、複数の設計案を素早く比較検討する初期段階の開発に有効だが、実際のクロック精度・電気的挙動・実機特有のタイミング問題までは再現しきれない限界がある。最終的な性能・タイミング検証は実機（ICE/JTAG/SWD経由）で行う必要がある。

あるファームウェア開発者が、ARM Cortex-M搭載の小型センサ端末で、エミュレータ上のシミュレーションでは正常に動作するのに、実機に書き込むと特定のタイミングでセンサ値の読み取りが失敗するという不具合に直面したとします。まずこの症状から、エミュレータでは再現できない「実機特有の電気的挙動やタイミング」が原因である可能性が高いと判断し、実機上での直接観測に切り替えることにしました。この端末は基板が非常に小型でJTAGの太いコネクタを実装する余地がなかったため、ピン数の少ないSWDを使ってデバッガを接続します。SWD経由でブレークポイントを設定し、センサ読み取り処理の直前・直後でCPUレジスタとメモリの値を観測したところ、センサとの通信直後にCPUが別の割込み処理へ切り替わり、通信のタイミング制約（一定時間内に次のコマンドを送る必要がある）を超過していたことが判明しました。もし高価なICEが利用可能であれば、CPU内部のバス状態までリアルタイムに追跡してより詳細な原因究明ができたはずですが、今回はSWD経由のレジスタ観測だけで原因を特定できたため、追加のICE調達は不要と判断しました。この事例のように、エミュレータでの開発初期検証と、実機でのICE/JTAG/SWDによる最終検証は役割が異なり、症状がタイミングや電気的挙動に起因する場合は必ず実機での観測に立ち返ることが、組込み開発者に求められる判断です。

5.1.3この節のまとめ

• クロスコンパイラはホストで動きターゲット向けコードを生成、リンカ/ロケータはターゲットの実メモリ番地に配置する
• JTAGは標準的な多ピンI/F、SWDは少ピンでARM向け、ICEは高価だが内部状態まで観測できる
• エミュレータは初期検証に有効だが電気的挙動/タイミングは再現不可＝最終検証は必ず実機で行う