デバッグとプログラミングインターフェース

JTAG/SWD は外部から CPU を制御するためのインターフェース（ブレークポイント、ステップ実行、書き込み、バウンダリスキャン）であり、DFU および UART ブートローダーはチップに内蔵されたファームウェア更新チャネルです。開発には SWD を使用し、量産ではまずブートローダーを書き込んでから一括で DFU による書き込みを行い、現場でのアップグレードには OTA を利用します——段階に応じて異なるインターフェースを使い分けます。

概要

マイコン（MCU）を取り巻く「インターフェース」は、実際には3つの異なる役割を担っています：⁠デバッグ⁠（CPUの一時停止、ブレークポイント、ステップ実行、メモリ読み書き）、⁠書き込み⁠（ファームウェアをフラッシュメモリに書き込む）、⁠生産検査⁠（ファームウェアなしでハンダ付けを検証）。各インターフェースを理解するには、まずそれがどのカテゴリに属し、どのような前提条件を必要とするかを明確にする必要があります。

重要な違い：JTAG/SWD は外部から CPU を制御するもので、チップがフリーズしていてもデバッグや修復が可能です。一方、DFU/UART ブートローダーはチップ自身がファームウェア更新に協力するもので、専用ハードウェアは不要ですが、ブートピン設定を誤ってファームウェアが書き換わってしまうとアクセスできなくなります。

JTAG (IEEE 1149.1)

1980年代、PCB のハンダ付けテストのために誕生しました（Joint Test Action Group）。その後、デバッグの標準規格としても採用されるようになりました。

複数のチップをジャグチェーン⁠（ドミノつなぎ）で直列接続できます（TDI → TDO → 次のチップの TDI）。これにより、1つのデバッグポートで基板全体の制御が可能です。電圧はターゲットに合わせて調整する必要があり（1.8V〜5V）、速度は通常 1〜50MHz です。

その3つの用途の中で、⁠バウンダリスキャンはその出自を最もよく表しています。JTAG を使用すると、チップの各ピンの電位を直接制御・読み取ることができ、⁠ファームウェアを一切実行せずに、PCB 上の2つのチップ間の配線が正しくハンダ付けされているかを確認できます。これは生産ラインテストの基盤となります。デバッグ（CPUの一時停止、ブレークポイント、メモリ/フラッシュの読み書き）や書き込みは、後に付加された機能です。

SWD (Serial Wire Debug)

ARM が Cortex シリーズのために設計した、JTAG の簡素化された代替規格です。JTAG の 4〜5 本の配線を 2 本に圧縮しました——SWDIO（双方向データ）+ SWCLK（クロック）、それに必須の GND です。デバッグ機能は劣化していません：ブレークポイント/ステップ実行/レジスタアクセス、フラッシュプログラミング、DP/AP メカニズムによるマルチコアデバッグが可能で、速度は 50MHz 以上（CoreSight）に達します。

選択ロジックは非常に単純です：Cortex-M の開発では一律 SWD を使用します。非 ARM、複雑な SoC、バウンダリスキャンが必要な場合は JTAG を選択します。迷った場合は JTAG ポートを完全に確保しておけば大丈夫です（JTAG ピンは SWD として再利用可能です）。

デバッカーハードウェアと OpenOCD

ソフトウェア側のハブは OpenOCD です。これはサードパーティ製ツールを仲介します。

flowchart LR
    GDB["gdb-multiarch<br>(ブレークポイント/ステップ実行/変数)"] <-->|"GDB リモートプロトコル<br>:3333"| O["OpenOCD"]
    O <-->|USB| P["デバッカー<br>ST-Link / J-Link / DAP"]
    P <-->|SWD / JTAG| T["ターゲットチップ"]

openocd -f interface/stlink.cfg -f target/stm32f4x.cfg   # GDB サーバー起動
gdb-multiarch firmware.elf
(gdb) target remote :3333

インターフェース側では ST-Link/J-Link/DAP-Link/FTDI などをサポートし、ターゲット側ではほぼすべての ARM + RISC-V + MIPS をカバーしています。オープンソースエコシステムにおいて、これが事実上の標準です。

チップに内蔵されたファームウェア更新チャネル

USB DFU

チップの Boot ROM（工場出荷時に固化されており、書き換え不可）が特定の条件を検出すると、チップを USB デバイスとして列挙させ、ホストが USB 経由で直接ファームウェアを送信します。

• STM32: BOOT0 をハイにして電源投入 → System Memory ブートローダー
• nRF52: 特定のレジスタ値 + リセット
• RP2040: BOOTSEL を押しながら電源投入 → 直接 USB ドライブとして表示され、ファームウェアをドラッグ＆ドロップするだけで書き込み完了（最も体験の良い DFU）

利点は追加ハードウェアがゼロであること——ユーザーが USB ケーブル1本持っていれば書き込み可能です。欠点は書き込みのみ可能で、デバッグができないことです。

UART Bootloader

Boot ROM の動作ですが、媒体がシリアルポート（XMODEM/YMODEM/カスタムプロトコル）に変わります。

• STM32: System ブートローダーが USART1 を監視
• ESP32: ROM ブートローダー、esptool が自動検出（または GPIO0 をローに）
• AVR: 工場出荷時には存在しない。まず ISP で書き込む必要がある（Arduino ブートローダーがこれに相当）
• MSP430: BSL

シリアルポートがあれば書き込み可能ですが、速度が遅いという代償があります。115200bps では約 10KB/s であり、数百 KB のファームウェアでは数十秒待たされることになります。

製品ライフサイクルにおける3つのチャネルの役割分担

flowchart LR
    DEV["開発期間<br>SWD/JTAG<br>デバッグ + いつでも書き込み可能"] --> FAC["生産ライン<br>まず SWD でブートローダー書き込み<br>その後 DFU で一括書き込み"]
    FAC --> FIELD["現場<br>APP 内蔵 DFU/OTA<br>ユーザーによる自己アップグレード"]

ロジックアナライザ: バスレベルでのデバッグ

デバッカーは「コードのどこが間違っているか」を解決しますが、ロジックアナライザは「⁠配線上で実際に何が起きているか⁠」を解決します——ファームウェアは正しく見えるが周辺デバイスが反応しない場合に、決定打となります。Saleae / DSLogic / PulseView にはすべてプロトコルデコーダーが内蔵されています：I2C（アドレス+データ+ACK を自動デコード）、SPI（フレーム単位で表示）、UART（ボーレートに応じて ASCII に変換）、CAN/LIN、1-Wire。また、プロトコルレベルのトリガー（例：「I2C でアドレス 0x68 が出現した時点でキャプチャ開始」）にも対応しています。

典型的なトラブルシューティング（I2C センサーが応答しない場合）：

flowchart TD
    S["I2C センサーが動作しない"] --> C["SDA/SCL の波形をキャプチャ"]
    C --> Q{"アドレス後に ACK があるか？"}
    Q -->|ACK なし| A["アドレス間違い / 配線不良 / チップ未給電"]
    Q -->|ACK あり| B{"レジスタ読み書き値は正しいか？"}
    B -->|不正| D["データシートでレジスタタイミングを確認"]
    B -->|正しい| E["バス側の問題ではない → ファームウェアロジックで調査"]

SPI Flash の不安定な動作も同様です。CS のタイミング、CLK の周波数、データの完全性をキャプチャし、物理層の問題をまず除外します。バスプロトコルの詳細については、シリアルバス を参照してください。

選択ガイド

参考文献

• JTAG: IEEE 1149.1 · ARM Debug Interface (ADIv5) リファレンス
• OpenOCD: openocd.org/doc
• SEGGER: wiki.segger.com (RTT/J-Link ドキュメントの品質は極めて高い)
• Sigrok/PulseView: sigrok.org (オープンソースロジックアナライザ)

キーワード: JTAG, SWD, SWDIO, SWCLK, OpenOCD, DFU, Boot ROM, ブートローダー, ST-Link, J-Link, DAP-Link, バウンダリスキャン, ロジックアナライザ