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

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

概要

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

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

JTAG (IEEE 1149.1)

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

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

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

SWD (Serial Wire Debug)

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

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

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

ソフトウェア側のハブは 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 をハイにして電源投入 → システムメモリブートローダー
• nRF52: 特定のレジスタ値 + リセット
• RP2040: BOOTSEL を押しながら電源投入 → 直接 USB ドライブとして表示され、ファームウェアをドラッグ＆ドロップするだけで書き込み完了（最もユーザーフレンドリーな DFU）

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

UART Bootloader

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

• STM32: システムブートローダーが 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, bootloader, ST-Link, J-Link, DAP-Link, バウンダリスキャン, ロジックアナライザ