組み込みシステムにおけるSWDインターフェースの仕組み

SWDインターフェースとは何か、そしてどのように機能するか

ARMベースの組み込み製品を出荷するチームは、起動時に次のようなおなじみのパターンに遭遇します。ファームウェアがロードされ、ボードの電源がオンになり、その後何も起こりません。出力もなく、応答もなく、明白な障害もありません。UARTログは沈黙しています。LEDは暗いままです。プロセッサを停止してレジスタ状態を検査する方法がなければ、調査はすぐに停滞してしまいます。

これはまさにSWDインターフェースが解決するために設計された状況です。PCB上のわずか2本の信号線を使用して、エンジニアはプロセッサへの直接的なパス（実行の停止、メモリの読み取り、ブレークポイントの設定、再フラッシュ）を得ることができます。この低ピンコストと深いアクセス性の組み合わせにより、SWDはARM Cortex組み込み設計全体でデフォルトのデバッグおよびプログラミングインターフェースとなっています。

シリアルワイヤデバッグプロトコル — 信号アーキテクチャとピンの役割

SWDは、SWDIOとSWDCLKという2つの必須信号を使用します。SWDCLKは、デバッグプローブからターゲットMCUにクロックを伝送します。SWDIOは双方向であり、ホストからのコマンドとターゲットからの応答を、ハーフデュープレックスのフレーミングを使用して単一のワイヤで伝送します。

半二重方式のデザインは、ターンアラウンドサイクルを通じて機能します。ホストがリクエストパケットの送信を完了すると、ラインの所有権はターゲットに切り替わり、確認応答と読み出しデータフェーズが行われます。プロトコルはこれらの遷移を正確に定義しているため、両側はいつ駆動し、いつリスニングするかを知っています。JTAGが4〜5本のラインで並列に送信するすべてをプロトコルがシリアル化するため、2本のワイヤで十分です。

2つのオプション信号がインターフェイスを拡張します。nRESETラインにより、プローブはターゲットにハードウェアリセットをアサートできます。これは、プロセッサがハングアップし、デバッグポートを介したソフトリセットが信頼できない場合に役立ちます。SWOピン（Serial Wire Output）は、ターゲットからプローブにトレースデータを運びます。ITMベースのprintfロギングとETM命令トレースは、どちらもSWOを出力パスとして使用します。

2本のワイヤで、ハル​​ト、メモリアクセス、フラッシュプログラミング、ブレークポイントを実現できます。SWOを3番目のピンとして追加すると、完全なJTAGトレースポートなしでリアルタイムトレースが追加されます。

電気的インターフェイスは簡単です。SWDIOは、どちらの側も駆動していないときにラインを高レベルに保つために、プルアップ抵抗（通常10 kΩ）を必要とします。SWDCLKはフローティングまたはプルダウンできます。プルアップ値は重要です。弱すぎると、高クロックレートでラインの充電が遅くなり、強すぎると、遷移中にプローブの駆動強度と競合します。

SWD対JTAG — 各プロトコルが適切な選択肢となる場合

SWDとJTAGは、どちらも同じARM Debug Interface（ADI）仕様から派生しています。それらは同じ基盤となるDebug PortとAccess Portアーキテクチャを共有しています。違いは物理的なトポロジーと信号数であり、デバッグ機能ではありません。

JTAGは、TCK、TMS、TDI、TDO、およびオプションでTRSTの5つの信号を使用します。複数のデバイスが単一のJTAGチェーンを共有できます。各デバイスはTDIからTDOにデータを渡し、デイジーチェーンを形成します。SWDはポイントツーポイントです。1つのプローブが1つのターゲットに接続されます。これが根本的なトレードオフです。

基準	SWD	JTAG
信号数	2（+オプションのSWO、nRESET）	4～5
トポロジー	ポイント・ツー・ポイント	デイジーチェーン（マルチデバイス）
マルチデバイスサポート	限定的（SWDマルチドロップ、ユニバーサルではない）	ネイティブ
トレース出力	SWO（シングルピン、帯域幅制限あり）	フルTPIUトレースポート（4ビットパラレル）
最適	シングルコアARM、ピン制約のあるPCB	マルチデバイスチェーン、高帯域幅トレース

今日のほとんどのARM Cortex-M設計では、SWDがプライマリインターフェイスとして出荷されています。小型フォームファクタPCBでのピン数圧力により、JTAGが利用可能なGPIOのかなりの部分を消費する可能性がある2線式設計が実用的になっています。デュアルコアSoCまたは複数のプログラマブルデバイスを搭載したボードでは、JTAGのチェーントポロジーが引き続き最適な選択肢となります。

多くのARMデバイスでは、同じ物理コネクタでJTAGとSWDを切り替えることが可能です。JTAGからSWDへの選択シーケンスでは、TCK/SWDCLKをクロッキングしながら、TMS/SWDIOで特定の16ビットマジック値を送信します。ほとんどのデバッグプローブはこれを自動的に処理します。ARM 10ピンおよび20ピンCortexデバッグコネクタは、同じフットプリントで両方のプロトコルを伝送するため、切り替え時にPCB設計を変更する必要はありません。

リソースが制約されたボードスペースを持つシングルコアARMターゲットの場合、SWDが実用的なデフォルトです。マルチデバイスチェーニングまたは高帯域幅パラレルトレースが確実な要件である設計には、JTAGを予約してください。

SWDコネクタ、ピンマッピング、および電気的互換性

ARM Cortexデバッグコネクタには、2つの標準サイズがあります。20ピンバージョン（0.1インチピッチ）は、評価ボードおよびほとんどのベンチデバッグアダプターで使用されるクラシックなフォームです。10ピンバージョン（0.05インチピッチ、2×5）は、ボードスペースが限られている量産ハードウェアでより一般的です。どちらもSWDIO、SWDCLK、nRESET、SWO、VTref（ターゲット電圧センス）、およびGNDを伝送します。

Tag-Connectは、量産ボードで人気のある代替手段です。コネクタを完全に排除し、スプリングロードされたプローブがPCB上の小さなパッドフットプリントに接触します。TC2030-IDCフットプリントは6つのパッドでSWDをカバーし、量産治具で広く使用されています。ボードコストはほぼゼロになり、フットプリントはタイトなレイアウトに収まるほど小さいです。

電圧互換性には注意が必要です。プローブはターゲットのI/O電圧と一致する必要があります。ほとんどの最新プローブはVTrefを検出し、それに応じてドライブレベルをシフトし、1.8 V、3.3 V、および5 Vターゲットをサポートします。レベルシフトなしで3.3 Vプローブを1.8 Vターゲットに直接接続すると、通信が最初は正常に見えても、時間の経過とともにターゲットのI/Oセルが損傷します。

• SWDIO プルアップ: 標準的な初期値は 10 kΩ (VCC へ)、SWDCLK 周波数が高い場合に信号ライズタイムが遅い場合は 4.7 kΩ に減らしてください
• トレース長: SWDIO および SWDCLK トレースは短く、整合させてください。高速スイッチング信号の長すぎるトレースは、パケットを破損する反射を引き起こします
• デカップリング: MCU の VDD ピンの近くに 100 nF のデカップリングコンデンサを配置してください。SWD トランザクションは、信号品質に影響を与える電流スパイクを発生させます
• GPIO 競合: 接続を試みる前に、ファームウェアで SWDIO および SWDCLK ピンが他のペリフェラルに再割り当てられていないことを確認してください

コネクタのピン配置、電圧レベル配線図、PCB レイアウトガイダンスの完全な参照については、 SWD コネクタのピン配置と配線リファレンスを参照してください。

組み込みシステムにおける SWD インターフェイス ― デバッグ、プログラミング、およびプロダクションでの使用

プロトコルを理解することは基本です。ほとんどの組み込みチームにとってより重要な質問は、SWDが製品ライフサイクルの全段階――初期の起動から製造プログラミング、フィールドメンテナンスまで――にどのように適合するかということです。各フェーズには異なる要件があり、SWDはすべて同じ2線式インターフェースで処理します。

SWDによるファームウェアフラッシングとインサーキットプログラミング

SWDは、ARM Cortex-MおよびCortex-Aターゲットの主要なインサーキットプログラミングパスです。ターゲットに既存のブートローダーは必要ありません。デバッグプローブはプロセッサのデバッグポートに直接接続され、コアを停止させ、メモリマップされたフラッシュコントローラを介してフラッシュに書き込みます。

プログラミングシーケンスは、ベンダーやツール間で一貫したパターンに従います。

• 接続：プローブがSWD通信を確立し、ターゲットのIDCODEを読み取ってデバイスIDを確認します
• 停止：プローブがデバッグポート経由でCortexコアを停止します
• 消去：プローブがターゲットRAMにロードされたフラッシュアルゴリズムを使用してターゲットフラッシュセクターを消去します
• プログラム：バイナリイメージがページ単位で書き込まれ、フラッシュアルゴリズムがターゲット上で実行されて各書き込みを実行します
• 検証: プローブは書き込まれたデータを読み戻し、ソースバイナリと比較します
• リセット: プローブはコアを解放し、ファームウェアの実行を開始します

フラッシュアルゴリズムはMCUベンダー固有です。OpenOCD、pyOCD、およびベンダーIDEはそれぞれこれらのアルゴリズムのライブラリを保持しています。ツールのデータベースに新しいMCUバリアントがまだ存在しない場合、アルゴリズムを手動で追加する必要があります。これは、生産立ち上げ中に新しいシリコンリビジョンを採用する際の一般的な問題点です。

SWDプログラミングには、主に2つのホスト側フローが存在します。ドラッグアンドドロッププログラミング（CMSIS-DAPおよびDAPLinkベースのプローブで使用）は、プローブをUSBマスストレージデバイスとして表示します。バイナリファイルをドロップすると、フラッシュシーケンスが自動的にトリガーされます。このアプローチはフィールド技術者にとって高速であり、ソフトウェアのインストールは不要です。OpenOCDを使用したGDB、またはSTM32CubeProgrammerやnrfjprogなどのベンダーCLIツールを使用したホスト制御フローは、より多くの制御を提供します。スクリプト、合否ログ、および自動テストシステムとの統合をサポートします。

プローブの選択とホスト側ツールチェーンの設定に関するガイダンスについては、以下を参照してください。 SWDデバッグプローブの選択と設定。

SWDCLK周波数は、実用的なプログラミング速度を設定します。ほとんどのCortex-Mターゲットは、安定した条件下で最大10 MHzのSWDCLKをサポートしますが、多くの量産治具では、温度やケーブル長の変化に対するマージンを維持するために4〜8 MHzで動作します。4 MHzでは、256 KBイメージのプログラミングは、通常、消去と検証を含めて10秒未満で完了します。ギャングプログラミング治具（1つのホストが4つまたは8つのボードを同時にプログラムする）は、サイクルタイムの目標を達成するために量産で一般的です。

テストポイントの配置は重要です。SWDIO、SWDCLK、GND、VCCのテストポイントは、フィクスチャ側からアクセス可能である必要があります。コンポーネント側に配置すると両面フィクスチャが必要になり、コストと複雑さが増します。製品リビジョン間で一貫した場所にグループ化すると、フィクスチャの再利用が容易になります。

リアルタイムデバッグ、トレース、CoreSight統合

SWDは、ARM CoreSightデバッグアーキテクチャのトランスポート層です。そのアーキテクチャを理解することで、プローブがターゲットに接続した後に実際に行えることがわかります。

CoreSightは、2つのポートタイプを介してデバッグアクセスを編成します。デバッグポート（DP）はSWDインターフェイスそのものであり、接続、認証、および最上位レベルの制御を処理します。アクセスポート（AP）はDPの後ろにあり、特定のリソースへのアクセスを提供します。AHB-APは、フルメモリマップへの読み書きアクセスを提供し、Core Debugレジスタはそのマップ内にあります。AHB-APを介して、プローブはコアが停止している間に、任意のメモリアドレス、ペリフェラルレジスタ、またはCPUレジスタを読み書きできます。

ブレークポイントとウォッチポイントは、Cortex-MコアのDWTおよびFPBユニットを介して機能します。ハードウェアブレークポイントは、実行が特定のアドレスに到達するとプロセッサを停止します。ウォッチポイントは、指定されたアドレスまたはアドレス範囲へのメモリ（読み取り、書き込み、または両方）アクセス時に停止します。Cortex-M4は通常、6つのハードウェアブレークポイントと4つのウォッチポイントを提供します。これらのカウントを超えると、フラッシュ内の命令を変更するソフトウェアブレークポイントが必要になり、それ自体にも制限があります。

Haltモードデバッグは、本質的に侵襲的です。プロセッサは停止し、時間依存のペリフェラル（ウォッチドッグタイマー、通信ペリフェラル、モーター制御ループなど）は、コアが停止している間も実行を継続するか、フォルトアウトします。リアルタイムシステムで作業するエンジニアは、タイミングが重要なセクションで非侵襲的なデバッグ方法を必要とします。

SWOトレースはこれに対処します。シリアルワイヤ出力ピンは、インストルメンテーショントレースマクロセル（ITM）からのデータ、およびETMを備えたコアでの命令トレースを運びます。ITMトレースにより、ファームウェアは32チャネルのソフトウェアFIFOにログメッセージを書き込むことができます。プローブは、コアを停止することなくリアルタイムでそれらを読み取ります。これは、printfデバッグの組み込み同等物ですが、UART出力と比較して実行時のオーバーヘッドがわずかです。典型的なITM書き込みは数クロックサイクルで完了し、データは毎秒数メガビットのレートでSWOを介して出力されます。

SWOが利用できない場合や、プローブがトレースをサポートしていない場合は、RTT（リアルタイム転送）が代替手段となります。RTTは、ターゲットRAM内の小さなリングバッファを使用します。プローブは、コアが実行中にデバッグポートを介してバッファを読み取ります。追加のピンは必要ありません。トレードオフはRAM消費であり、典型的なRTTバッファは、ログ量に応じて512バイトから4KBを使用します。また、SWOと比較してわずかなレイテンシがあります。

ブレークポイント、SWOトレース設定、RTTの手動設定については、 SWDデバッグ環境セットアップの手順を参照してください。

産業用HMI、IoT、および生産組み込みシステムにおけるSWD

ARMベースの産業用HMIコントローラ、IoTエッジノード、モーター駆動MCU、ビルディングオートメーションデバイス全体で、SWDは製品ライフサイクルにおいて開発デバッグ、製造プログラミング、フィールドメンテナンスの3つの異なる役割を果たします。各役割には異なる要件があり、インターフェースは同じ物理接続を通じてこれらすべてを処理します。

産業用HMIおよびオートメーションコントローラ は、主に製造プログラミングおよびフィールドファームウェアアップデートにSWDを使用します。HMI製造ラインにおける典型的なテスト治具は、SWDIO、SWDCLK、GND、VCCテストポイントにポゴピンコンタクトを使用します。ホストはスクリプト化されたフラッシュシーケンスを実行し、ボードのシリアル番号で結果を記録し、リワークのために障害をフラグ付けします。ボードあたりのサイクルタイムは、機能テストステップを含めて通常15〜30秒です。SWDインターフェース自体は、その合計に10秒未満を追加します。

産業用IoTエッジノード 多くの場合、TrustZoneまたは読み出し保護が有効化されたCortex-M33またはCortex-M4ターゲットで、本番環境で実行されます。開発中は、SWDは完全なデバッグアクセスを提供します。出荷前に、ファームウェアは読み出し保護を有効化します。これはオプションバイトまたはヒューズレジスタへの一回限りの書き込みであり、SWDデバッグアクセスを無効化し、メモリの読み出しを防止します。フラッシュの内容はデバッグポート経由で読み取れなくなります。これは、出荷製品におけるファームウェアIPを保護するための標準的なメカニズムです。

読み出し保護設定後にSWDを再有効化するには、一括消去が必要です。デバイスは、デバッグアクセスを再度開く前に、すべてのフラッシュを消去します。これはファームウェアを保護しますが（イメージを読み出して復元する方法はありません）、保証修理または工場での rework では、デバイスを最初から再フラッシュする必要があります。本番稼働開始後ではなく、最初の返品ユニットが到着する前に、この点を考慮した rework フローを構築してください。

モーター駆動およびパワーエレクトロニクスMCU タイミング制約を追加します。これらの設計の多くは、通常の動作でSWDピンをGPIOとして使用します。MCUは、ブート後にSWDIOとSWDCLKを他の機能にリマップします。リマップ後にプローブを接続すると、サイレントに失敗します。解決策はデバッグウィンドウです。これは、GPIOまたは特定のブート条件によってトリガーされる、起動時の短い期間であり、ファームウェアはこのウィンドウ中にSWDをアクティブに保持してからリマップします。これにより、プローブはウィンドウ中に接続し、リマップが発生する前にコアを停止させることができます。

STM32H7シリーズやNXP i.MX RTなどの産業用MCUでますます一般的になっているデュアルコアSoCでは、SWDマルチドロップまたはコアごとの個別のデバッグコネクタが必要です。SWDマルチドロップは、同じSWDCLK/SWDIOライン上で各コアに一意のターゲットIDを割り当てます。すべてのプローブがこれをサポートしているわけではありません。新しい設計でデュアルコアSWDデバッグアーキテクチャを採用する前に、プローブのファームウェアバージョンとマルチドロップサポートを確認してください。

CI/CD統合は、接続製品を出荷する組み込みチームでは標準的なプラクティスになっています。OpenOCD、pyOCD、およびほとんどのベンダーCLIツールは、ビルドパイプラインが直接呼び出すことができるコマンドラインインターフェースを公開しています。典型的な自動テストステップでは、ファームウェアをフラッシュし、デバッグポート経由でパワーオンセルフテストを実行し、既知のメモリ位置からパス/フェイル結果を読み取り、結果をログに記録します。これにより、フラッシュ書き込みの失敗や基本的なファームウェアの障害が、手動テストサイクルだけでなく、すべてのビルドで検出されます。

STONE HMIは、自動化プロジェクト全体で構造化されたファームウェア開発プロセスを適用します。

組み込み製品チームにとって、そのようなプロセス規律は開発ラボを超えて重要です。本番プログラミング、自動テスト、およびフィールド rework 手順が、最初の生産実行前に定義およびテストされると、納品リスクは大幅に低下します。そのワークフローにおけるSWDの役割は、単なるデバッグの利便性ではなく、ARMベースのハードウェアで再現可能で検証可能な本番プログラミングを可能にするメカニズムです。

SWDインターフェースに関するよくある質問

SWDインターフェースは何に使用されますか？

SWDは、ARM Cortexプロセッサのデバッグアクセス、ファームウェアフラッシュ、およびリアルタイムトレースを提供します。開発中のブリングアップデバッグ、製造時の生産プログラミング、フィールドファームウェアアップデートといった製品ライフサイクルの全体をカバーします。アーキテクチャとプログラミングワークフローについては、上記のセクションで詳細に説明しています。

SWDにはいくつのピンが必要ですか？

SWDには2つのピンが必要です：SWDIOとSWDCLK。3番目のピンであるnRESETはオプションですが、ターゲットが未知の状態にある可能性のある場合、プローブ接続を確実に機能させるために推奨されます。4番目のピンであるSWOは、トレース出力機能を追加します。信号の完全な内訳については、H3 1.1を参照してください。

SWDは、開発デバッグだけでなく、生産プログラミングにも使用できますか？

はい — SWDを介した生産プログラミングは、ARMベースの組み込み製品において標準的な手法です。ポゴピン治具、ギャングプログラマ、およびスクリプト化されたCLIツールはすべて、ボリュームフラッシュプログラミングのためにSWDインターフェースを使用します。プログラミングシーケンス、速度制限、および治具設計の要因については、H3 2.1で説明しています。

ファームウェアフラッシュにおけるSWDとUARTの違いは何ですか？

UARTベースのフラッシングは、MCUのROMまたはフラッシュに既に存在するブートローダーを使用します。この場合、プロセッサは実行中で、ブートローダーがアクティブである必要があります。SWDはプロセッサを完全にバイパスし、デバッグポートを介してフラッシュに直接書き込みます。SWDは、ターゲットにファームウェアがない場合、イメージが破損している場合、またはプロセッサがロックアップしている場合でも機能します。

SWDはすべてのARM Cortexプロセッサでサポートされていますか？

SWDは、すべてのARM Cortex-MプロセッサおよびほとんどのCortex-Aプロセッサでサポートされています。これはARM Debug Interface（ADI）仕様の一部であり、Cortex-M0以降のCortex-Mシリコンに含まれています。古い、または深く埋め込まれたCortex-A構成の一部ではJTAGのみが公開されていますが、これらは現在の設計では一般的ではありません。

出荷製品でファームウェアを保護するためにSWDを無効にするにはどうすればよいですか？

ほとんどのARM Cortex-M MCUは、リードアウト保護メカニズムを提供します。これは、オプションバイトまたはセキュリティヒューズへの1回限りの書き込みで、デバッグポートへのアクセスを無効にし、メモリの読み戻しを防ぎます。再度有効にするには、ファームウェアを破壊する完全なマス消去が必要です。セキュリティワークフローとリワークの考慮事項については、H3 2.3で説明されています。