Embedded Test 08 · デバッグポート経由の観測 — グレーボックスという反則

Chapter 08

デバッグポート経由の観測 — グレーボックスという反則

この章のゴール.

SWD/JTAG が使える場合に、ブラックボックスを一部グレーボックス化して観測を強力にできること、 ただしそれが「製品の状態」とは限らない前提と、非侵襲的なトレース観測の使い方を理解すること。

この章で使う既出の用語（定義は各リンク先）. オラクル（01 章 8 節）、刺激（02 章 1 節）、電源（02 章 2 節）、UART（05 章 1 節）、エラー処理（06 章 6 節）

1. デバッグポートは「半分中が見える」

03 章〜07 章は完全に外からの観測だった。だが開発中の機器にはデバッグポート（SWD、JTAG）が生きていることが多い。 ここを使うと、実行を止めずにメモリ・レジスタ・変数を覗く、特定関数で止める、トレースを取ることができる。純粋なブラックボックスではなくなるが（グレーボックス）、テストの観測力とデバッグ効率が跳ね上がる。

デバッグポートは「半分中が見える」——強力だが製品とは限らないPC + プローブJ-Link / CMSIS-DAPOpenOCD / pyOCDSWD/JTAGMCU（内部が見える）メモリ・レジスタ・変数ブレーク・トレース止めない観測RTT / SWO / ITM止める観測ブレーク=時間が壊れる落とし穴: 製品ではロック／読み出し保護される。「開発機 ≠ 製品」最終受け入れは純ブラックボックスで。グレーは開発中の観測・原因究明に使う
図8-1　デバッグポート経由のグレーボックス観測。

2. 何ができるか

機能テストでの使い方
メモリ/変数の読み出し内部状態をオラクルの観測点に。UART を汚さず高頻度に読める
メモリ書き込み状態を強制注入（テストの前提づくり）、フォールト注入
ブレークポイント「この関数に到達したか」「異常経路を通ったか」を検出
ウォッチポイント「この変数が書き換わった瞬間」を捕まえる
RTT / SWO トレース（後述）実行を止めずにログ・変数を高速に流し出す
コアダンプクラッシュ時の状態を丸ごと（バイナリ編 17 章）

道具は OpenOCD/pyOCD + gdb、J-Link（pylink）、各社 IDE。pyocd は Python から read_memory/write_memory ができ、自動テストに組み込みやすい。

from pyocd.core.helpers import ConnectHelper
with ConnectHelper.session_with_chosen_probe() as session:
    t = session.target
    val = t.read_memory(0x20000100)          # 状態変数のアドレス（マップから、バイナリ編 [05 章](../binary/05_ELFファイル.md)）
    assert val == EXPECTED_STATE

3. 止めない観測 — RTT と SWO

ブレークで止めると、リアルタイム性が壊れて無線が切れる・タイミングが変わる。止めずに観測する手段が重要。

止めない観測は、タイミングを乱さずに内部を見るための鍵である（観測が対象を乱す問題への対策、14 章）。

4. グレーボックスの落とし穴 — 「開発機 ≠ 製品」

デバッグポートで見た振る舞いが、出荷される製品の振る舞いとは限らない。

だから、最終的な受け入れは純粋なブラックボックスで行い、グレーボックスは開発中の観測・原因究明に使う、と役割を分ける。 「デバッグポートが製品でちゃんとロックされているか」自体もブラックボックスのテスト項目である（17 章）。

5. フォールト注入の下見

デバッグポートは、わざと壊すテストの入口にもなる。

これは電源グリッチ・電磁フォールト（17 章のサイドチャネル/フォールト）の「配線でできる版」で、安全に異常系を試せる。

6. 何をオラクルにするか

7. 手を動かす

止める観測と止めない観測

この章のポイント