組み込みおよびHMIシステム向けのSWDデバッグワークフロー

SWD接続の確立は最初のステップにすぎません。プローブがターゲットを認識した後、より困難な問題が発生します。デバッグセッションが静かに誤動作したり、UART出力なしでフォルトベクトルが発生して説明できなかったり、または生産ラインが同じ2線式インターフェイスを介した決定的な合格/不合格検証を必要としたりする場合です。この記事では、セッションの初期化、フォルトの分離、およびプロダクションデバッグ戦略といったアクティブなデバッグワークフローに焦点を当てます。このすべてを支える物理層とプロトコル層については、 SWDインターフェイスアーキテクチャとピンの役割を参照してください。

SWDデバッグワークフロー、フォルト分離、およびプロダクションデバッグ戦略

組み込みターゲットでの信頼性の高いSWDデバッグセッションの確立

接続チェックにより、プローブがワイヤ全体でビットをクロックできることが確認されます。デバッグセッションにはさらに多くのことが必要です。デバッグアクセスポート (DAP) が初期化され、ターゲットが既知のリセット状態に達し、プローブが意味のある作業を開始する前に安定した SWCLK 周波数をネゴシエートする必要があります。これらの各ステップは個別に失敗する可能性があり、ほとんどのデバッグツールのエラーメッセージは 3 つの失敗すべてを同じように扱います。

リセットシーケンスは、ARM Cortex-M ターゲットで最も一般的なサイレント障害ポイントです。SYSRESETREQ は完全なシステムリセットをアサートし、ほとんどのペリフェラルを再初期化します。VECTRESET はプロセッサコアのみをリセットし、ペリフェラルの状態はそのまま維持されます。ペリフェラルがクロックゲートまたは電源ドメインを保持しているターゲットで VECTRESET を選択すると、初期化されていないペリフェラルにアクセスしようとしたときにすぐにフォルトが発生するコアにデバッグセッションがアタッチされたままになる可能性があります。ほとんどの開発ボードは、どちらの選択肢も許容します。カスタム電源シーケンスを備えた量産ハードウェアは、そうでないことがよくあります。

クロックスピードの選択も同様のロジックに従います。保守的な SWCLK レート（通常は 1 MHz 以下）から開始すると、プローブが DAP 初期化を開始する前に、ターゲットがリセット後に安定する時間を与えます。セッションが実行されたら、4～10 MHz に引き上げると、フラッシュプログラミング時間とメモリ読み取りレイテンシが短縮されます。長距離 SWDIO および SWDCLK 信号仕様のトレースまたはケーブル接続されたターゲットでは、数 MHz を超えるとライン反射が実際の制約となります。

マルチドロップ SWD はさらにレイヤーを追加します。2 つ以上のデバイスが同じ SWD バスを共有する場合（メイン MCU とディスプレイコントローラーの両方が SWD を公開する HMI ボードでは一般的）、プローブは DAP 初期化の前にターゲット選択シーケンスを発行する必要があります。マルチドロップバスでこの手順をスキップすると、通常、配線障害とまったく同じように見える DAP 初期化の失敗が発生します。

既知の良好な配線チェックの後でデバッグセッションが失敗した場合、最初の質問は、以前のファームウェアビルドがデバイスオプションバイトのデバッグ無効ビットをセットしたかどうかということです。ロックされた DAP は、切断された DAP と同じエラーを返します。

ロックされた DAP と配線障害を区別するには、シリコンベンダーがサポートしている場合、マスエラゼアンロックシーケンスを通じてデバイスの読み出し保護レジスタを確認する必要があります。一部のベンダーはサポートしておらず、ロックされたデバイスはデバッガーから永久にアクセスできなくなります。

アクティブSWDデバッグセッション中のフォールト分離テクニック

Cortex-Mターゲットがハードフォールトに入り、UARTペリフェラルがフォールトソースである場合、読み取るべきシリアル出力はありません。CPUがフォールトハンドラで停止した後もDAPにはアクセス可能です。DAPを介してConfigurable Fault Status Register (CFSR)、Hard Fault Status Register (HFSR)、およびフォールトアドレスレジスタ (BFAR, MMFAR) を直接読み取ることで、動作中のペリフェラル出力なしに完全なフォールト診断が可能です。これは、UARTが配線されているボードであっても、ハードウェアの立ち上げ中にSWDデバッグアクセスを開いたままにしておく主な理由です。

ブレークポイント戦略は、ほとんどのエンジニアが予想する以上に重要です。Cortex-MのFlash Patch and Breakpoint (FPB) ユニットは、コアバリアントによって通常4〜8個の限られた数のハードウェアブレークポイントを提供します。ソフトウェアブレークポイントは、実行時にフラッシュにパッチが適用されたBKPT命令を使用します。フラッシュ常駐コードでこれらを混在させると問題が発生します。フラッシュ内のソフトウェアブレークポイントは命令ストリームを変更するため、一部のブートローダーやセキュリティモニターが使用するフラッシュチェックサムが無効になります。セキュリティが重要な立ち上げ中は、フラッシュ常駐コードにはハードウェアブレークポイントを使用してください。

Data Watchpoint and Trace (DWT) ユニットによるウォッチポイントは、実際にはあまり活用されていません。DWTコンパレータを設定して特定のメモリアドレスを監視すると、デバッガは、破損がフォールトベクターに伝播する前に、そのアドレスに値が書き込まれた瞬間にCPUを停止させることができます。これは、スタックオーバーフローや未初期化ポインタの書き込みを追跡する際に、ブレークポイントで二分法を使用するよりもはるかに高速です。

RTOS対応デバッグは特別な注意に値します。FreeRTOSまたはThreadXアプリケーションに接続されたベアメタルデバッグセッションでは、フォールトを引き起こしたスレッドではなく、実行中だったスレッドのスタックが表示されます。プローブはRTOSスレッド認識をサポートする必要があります。これは、正しいRTOSプラグインをロードし、それを正確なカーネルバージョンと照合することを意味します。プラグインの不一致は、もっともらしく見えますが不正確なスタックトレースを生成します。

1つの実用的な注意点：ライブセッション中にDAPを介してペリフェラルレジスタを読み取ると、ステータスフラグがクリアされる可能性があります。多くのCortex-MデバイスのUARTステータスレジスタは、読み取り時にクリアされます。ライブ式ウィンドウでUARTステータスレジスタを監視すると、ファームウェアが待機していたフラグが消費され、デバッグセッションが閉じられたときに消えるような方法でアプリケーションが停止します。

本番およびエンドオブライン環境でのSWDデバッグ

本番SWDデバッグの目標は、開発デバッグとは異なります。セッションは探索的ではなく、固定シーケンス（消去、プログラム、検証、ブート確認、オプションでロック）を実行します。成功の尺度は、診断の深さではなく、サイクルタイムと再現性です。本番ラインで開発プローブのワークフローを使用しようとするチームは、通常、それが遅すぎ、手動手順に依存しすぎていることに気づきます。

自動化されたセッションスクリプティングがこれを解決します。J-Linkスクリプトファイル、pyOCDスクリプト、OpenOCD TCLシーケンスは、手動介入なしでエンドラインフロー全体を駆動できます。典型的なスクリプトは、ターゲットの消去、ファームウェアイメージの書き込み、チェックサムブロックの読み戻し、ブートベクトルの確認、およびログファイルへのパス/フェイル結果の記録を行います。典型的な組み込みHMIファームウェアイメージでは、フラッシュサイズとクロックスピードに応じて、ユニットあたり10〜30秒のサイクルタイムが実現可能です。

完全なデバッグ機能なしの専用フラッシュプログラミングワークフローの場合、専用SWDフラッシュプログラミングツールは、より高速なサイクルタイムと自動テストフィクスチャへの簡単な統合を提供します。トレードオフとして、プログラマーのみのツールはDAP経由でフラッシュ後のブート確認を実行できず、代わりに機能テストステップに引き渡します。

デバッグアクセスロックダウンは、技術的な決定であると同時にビジネス上の決定でもあります。エンドラインプログラミング後に読み出し保護を有効にすると、ファームウェアIPは保護されますが、返却されたユニットでのフォルトレジスタの読み出し能力は排除されます。要求の厳しい産業環境に出荷するチームは、フィールドRMA分析のために、ロックされていないユニットの小さな母集団を保持するか、DAPが署名付き認証情報でのみアクセス可能であるベンダー固有のデバッグ認証メカニズムを使用することがよくあります。

HMIボードには、メインアプリケーションMCU、ディスプレイコントローラー、場合によってはタッチコントローラーなど、複数のSWDターゲットが同じボード上に搭載されていることがよくあります。これらを単一のデバッグセッションで管理するには、マルチドロップSWD構成またはプローブをターゲット間で切り替えるフィクスチャのいずれかが必要です。生産ラインでターゲット間でケーブルを再接続することは信頼性のリスクです。プローブ切り替えを備えた固定フィクスチャは、ボリューム生産ではより良い選択肢となります。

STONE HMIエンジニアリングチームはIEC 61508に準拠したプラクティスに従っています。

直面しているチームにとって HMI製造における組み込みデバッグの課題、プロセス規律が最終ラインシーケンスが確定する前の治具設計段階で重要であるということです。デバッグアクセスポリシー、ロックダウンタイミング、治具アーキテクチャを早期に正しく設定することで、生産が本格化する際の高価な手戻りを回避できます。

SWDヘッダー用のPCBスペースは、繰り返されるトレードオフです。開発中は、4ピンヘッダーが実装されていると便利です。生産では、ピンヘッダーをなくし、ポゴピン治具でアクセスするテストパッドを使用することで、そのスペースを確保し、コネクタの摩耗を低減します。DAPが閉じられた後、ヘッダーは出荷後には何の役にも立たなくなるため、フィールドサービス性に関する実装済みヘッダーの主張は弱まります。

よくある質問

SWDデバッグは、ターゲットファームウェアの実行中に使用できますか？
はい。SWDは、CPUを停止することなく、DAPを介したライブ実行中の非侵入的なメモリおよびレジスタ読み取りをサポートします。これには、バックグラウンドメモリアクセスをサポートするプローブが必要です。すべての低コストプローブがこれを実装しているわけではありません。ライブレジスタ読み取りの実際的な制限については、上記の障害分離セクションを参照してください。

SWD配線が正しく見えるのに、「ターゲットが接続されていません」というエラーが発生するのはなぜですか？
上記のセッション設定セクションでは、3つの主な原因を詳細に説明しています。ファームウェアでロックされたDAP、ターゲットの現在のクロック状態に対するSWCLK周波数の誤り、およびリセットシーケンスの欠落または誤りです。マルチドロップバスでは、ターゲット選択シーケンスの欠落が同じエラーを生成します。

すべてのARM Cortex-MデバイスでSWDデバッグはサポートされていますか？
SWDデバッグはARM CoreSightアーキテクチャの一部であり、Cortex-M0、M0+、M3、M4、M7、M23、M33コアでサポートされています。特定のデバイスがDAPを公開するかどうかは、シリコンベンダーの実装に依存します。コスト削減のため、DAPを無効化または省略している部品もあります。SWDデバッグアクセスが可能であると仮定する前に、デバイスのレファレンスマニュアルを確認してください。

SWDデバッグとSWDプログラミングの違いは何ですか？
SWDプログラミングは、2線式インターフェースを使用してフラッシュにファームウェアを書き込みます。SWDデバッグはさらに進んで、実行中のCPUの停止、レジスタの読み取り、ブレークポイントの設定、メモリウォッチポイントをサポートします。専用のSWDプログラマーはフラッシュ書き込みパスのみを処理し、量産用途ではより高速でシンプルですが、フラッシュ書き込み後の起動確認や障害診断は実行できません。

組み込み製品開発で最も時間を浪費する原因となるのは、SWDデバッグを単一のワークフローを持つ単一のツールとして扱うことです。セッション確立、障害分離、量産検証は、それぞれ異なる失敗モードと異なるツール要件を持っています。これらの3つのフェーズを分離し、それぞれを意図的に設定したエンジニアは、通常、立ち上げ時間と量産歩留まりの両方が向上することに気づくでしょう。HMIプログラムで組み込みデバッグサポートを評価するプロジェクトマネージャーにとって、早期に尋ねるべき質問は、エンジニアリングチームが開発プローブがベンチにあるだけでなく、定義されたエンドオブラインデバッグポリシーを持っているかどうかです。