--- title: デバッグとプログラミングインターフェース url: https://doc.liz6.com/ja/hardware/10-practices-and-tools/03-debug-and-programming-interfaces locale: ja area: hardware tags: - hardware - practices-and-tools date: 2026-06-30 modified: 2026-07-19 description: JTAG/SWD は外部から CPU を制御するためのインターフェース（ブレークポイント、ステップ実行、書き込み、バウンダリスキャン）です。DFU および UART ブートローダーはチップに内蔵されたファームウェア書き込みチャネルです。開発には SWD を使用し、量産ではまずブートローダーを書き込み、その後一括で DFU による書き込みを行います。現場でのアップグレードには OTA を利用します——段階に応じて異なるインターフェースを使い分けます。 --- # デバッグとプログラミングインターフェース > JTAG/SWD は外部から CPU を制御するためのインターフェース（ブレークポイント、ステップ実行、書き込み、バウンダリスキャン）です。DFU および UART ブートローダーはチップに内蔵されたファームウェア書き込みチャネルです。開発には SWD を使用し、量産ではまずブートローダーを書き込み、その後一括で DFU による書き込みを行います。現場でのアップグレードには OTA を利用します——段階に応じて異なるインターフェースを使い分けます。 ## 概要 MCU 周辺の「インターフェース」は、実質的に3つの異なる役割を担っています：**デバッグ**（CPU の一時停止、ブレークポイント、ステップ実行、メモリ読み書き）、**書き込み**（ファームウェアを Flash に書き込む）、**生産テスト**（ファームウェアなしでハンダ付けを検証）。各インターフェースを理解するには、まずそれがどのカテゴリに属し、どのような前提条件を必要とするかを区別することが重要です。 | インターフェース | 配線数 | 機能 | 前提条件 | |---|---|---|---| | JTAG | 4~5 | デバッグ + 書き込み + バウンダリスキャン | 外部デバッガーが必要 | | SWD | 2 | デバッグ + 書き込み（ARM Cortex） | 外部デバッガーが必要 | | UART ブートローダー | 2 | 書き込みのみ | チップの Boot ROM に内蔵 | | USB DFU | USB ケーブル1本 | 書き込みのみ | チップの Boot ROM に内蔵 | | ISP/ICSP | 6ピン | 書き込み（AVR シリーズ） | プログラマーが必要 | 重要な違い：JTAG/SWD は**外部から CPU を制御**するもので、チップが故障していてもデバッグや修復が可能です。一方、DFU/UART ブートローダーは**チップ自身が連携してファームウェアを書き込む**もので、専用ハードウェアは不要ですが、ファームウェアによって boot ピンの設定が壊れてしまうとアクセスできなくなります。 ## JTAG (IEEE 1149.1) 1980年代に PCB のハンダ付けテストのために誕生しました（Joint Test Action Group の略）。その後、デバッグの標準規格としても採用されました。 | ピン | 正式名称 | 役割 | |---|---|---| | TMS | Test Mode Select | 内部ステートマシンを駆動 | | TCK | Test Clock | クロック信号 | | TDI | Test Data In | データ入力 | | TDO | Test Data Out | データ出力 | | TRST | Test Reset | リセット信号（オプション） | 複数のチップを**ジャグチェーン**（ドミノつなぎ）で直列接続できます（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）に達します。 | | JTAG | SWD | |---|---|---| | 配線数 | 4~5 | 2 | | 機能 | 全機能 + バウンダリスキャン + ジャグチェーン | デバッグ + 書き込み、十分実用的 | | 対応範囲 | ほぼすべてのチップ（FPGA/DSP含む） | ARM Cortex シリーズ | | PCB 占用 | 多い | 少ない、2本の配線ならどこにでも引ける | 選択ロジックは非常に単純です：**Cortex-M の開発では一律 SWD** を使用します。非 ARM、複雑な SoC、バウンダリスキャンが必要な場合は JTAG を選択します。迷った場合は JTAG ポートを完全に確保しておけば大丈夫です（JTAG ピンは SWD として再利用可能です）。 ## デバッカーハードウェアと OpenOCD | デバッカー | インターフェース | 価格 | 位置づけ | |---|---|---|---| | ST-Link V2 | SWD | $2〜10（互換品） | STM32 学習の第一選択 | | DAP-Link (CMSIS-DAP) | SWD+JTAG | $5〜15 | オープンソース、汎用 ARM | | J-Link (SEGGER) | SWD+JTAG | $20〜1000 | プロフェッショナル向け：高速、RTT、無限ブレークポイント | | FT2232H | JTAG | $10〜20 | OpenOCD との相性抜群の万能ツール | | Raspberry Pi Pico | SWD | $4 | picoprobe をフラッシュするだけでデバッカーに早変わり | ソフトウェア側のハブは **OpenOCD** です。OpenOCD はサードパーティ製ツールを仲介します。 ```mermaid flowchart LR GDB["gdb-multiarch
(ブレークポイント/ステップ実行/変数)"] <-->|"GDB リモートプロトコル
:3333"| O["OpenOCD"] O <-->|USB| P["デバッカー
ST-Link / J-Link / DAP"] P <-->|SWD / JTAG| T["ターゲットチップ"] ``` ```bash 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つのチャネルは製品ライフサイクルの中でそれぞれの役割を果たす ```mermaid flowchart LR DEV["開発期間
SWD/JTAG
デバッグ + 随時書き込み"] --> FAC["生産ライン
まず SWD でブートローダー書き込み
その後 DFU で一括書き込み"] FAC --> FIELD["現場
APP 内蔵 DFU/OTA
ユーザーによる自己アップグレード"] ``` ## ロジックアナライザ：バスレベルでのデバッグ デバッカーは「コードのどこが間違っているか」を解決しますが、ロジックアナライザは**「配線上で実際に何が起きているか」**を解決します——ファームウェアは正しそうに見えるが、周辺デバイスが反応しない場合に、これを使って決定的な証拠を突き止めます。Saleae、DSLogic、PulseView にはすべてプロトコルデコーダが内蔵されています：I2C（アドレス+データ+ACK を自動デコード）、SPI（フレーム単位で表示）、UART（ボーレートに従って ASCII に変換）、CAN/LIN、1-Wire。また、プロトコルレベルのトリガー（例：「I2C でアドレス 0x68 が出現した時点でキャプチャ開始」）にも対応しています。 典型的なトラブルシューティング（I2C センサーが応答しない場合を例に）： ```mermaid flowchart TD S["I2C センサーが動作しない"] --> C["SDA/SCL の波形をキャプチャ"] C --> Q{"アドレス後に ACK があるか？"} Q -->|ACK なし| A["アドレス間違い / 配線不良 / チップ未給電"] Q -->|ACK あり| B{"レジスタの読み書き値は正しいか？"} B -->|正しくない| D["データシートでレジスタタイミングを確認"] B -->|正しい| E["バス側の問題ではない → ファームウェアロジックで調査"] ``` SPI Flash の不安定な動作も同様です。CS のタイミング、CLK の周波数、データの完全性をキャプチャし、物理層の問題をまず除外します。バスプロトコルの詳細については、[シリアルバス](/hardware/06-interfaces-and-communication/02-serial-bus-protocols.md) を参照してください。 ## 選択ガイド | チップ/シナリオ | 推奨 | |---|---| | STM32 開発 | SWD (ST-Link) | | nRF52 開発 | SWD (J-Link / DAP-Link) | | ESP32 開発 | シリアルポート (内蔵ブートローダー、esptool) | | RP2040 開発 | SWD または USB ドラッグ＆ドロップ | | AVR (Arduino) | ISP (6-pin) | | ARM Linux カーネルデバッグ | JTAG (OpenOCD + GDB) | | FPGA | JTAG (Vivado/Quartus 付属) | | 現場でのファームウェアアップグレード | DFU / OTA | | センサー/周辺デバイスが応答しない | ロジックアナライザでバスをキャプチャ | | 生産ラインテスト | JTAG バウンダリスキャン | ## 参考文献 - **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, バウンダリスキャン, ロジックアナライザ*