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

このページの目次

ファームウェアの書き込み後にシリアル通信が応答しなくなった場合、まずアプリケーション通信、ダウンロードエントリポイント、またはハードウェアデバッグアクセスのいずれが失われたかを判断する必要があります。これらは依存関係が異なります。アプリケーションがクラッシュしている場合でも、ROMダウンロードは依然として実行可能である可能性があります。また、デバッグポートは電源、配線、またはセキュリティ設定によりアクセス不可となることもあります。「JTAG/SWDなら必ずブランク化を回避できる」や「USBで書き込めればデバッグも可能」といった一般論は当てはまりません。

能力機能依存関係
コアデバッグ一時停止、ステップ実行、ブレークポイント、レジスタ/メモリアクセスチップのデバッグモジュール、権限、プローブおよびサービスサポート
ファームウェアプログラミングイメージの消去、書き込み、検証プログラミングインターフェース/アルゴリズム、ストレージ設定および動作条件
バウンダリスキャンカバー対象のピン/配線に対してテストステートを印加および取得バウンダリユニット、BSDL、テストベクトルおよび基板レベルの連携
ROM/ブートローダーダウンロードブート段階でイメージを受信指定されたエントリポイント、転送プロトコルおよびイメージ形式
オンラインアップグレード実行中に受信し、ファームウェアを切り替えサービス、検証、電源断からの復旧およびバージョンポリシー

JTAG:伝送インターフェースはすべてのテスト能力を保証しない

JTAGの一般的な信号はTCK、TMS、TDI、TDOであり、TRSTの有無は実装に依存します。TMSはTCKの立上がり/立下がりエッジでTAP状態機械を駆動し、TDI/TDOは選択されたレジスタへのシリアル入力/出力を行います。デバッグモジュールとバウンダリスキャンは、関連する構造の上に構築された異なる用途です。JTAG端子を持つチップすべてが、必要なコアデバッグまたは完全なバウンダリスキャンをサポートしているわけではありません。

ドミノ接続(菊花連鎖)では、通常、1つのデバイスのTDOが次のデバイスのTDIに接続されます。ホストはチェーンの順序や各デバイスの命令レジスタ長などの設定を知る必要があります。他のデバイスはBYPASSを使用してシフトオーバーヘッドを削減できますが、物理チェーンから自動的に消えるわけではありません。混合電圧ドメインも一致させる必要があり、すべてのJTAGターゲットが5Vを受け入れると仮定してはいけません。

バウンダリスキャンは、アプリケーションファームウェアを実行せずに一部のデジタル相互接続をチェックできますが、「各ピンを直接制御できる」わけではありません。アナログ、電源、高速専用ピン、およびバウンダリユニットを持たないネットワークはカバーされない可能性があります。また、テスト時には基板の他のドライバとの競合を避ける必要があります。BSDLはデバイスのバウンダリ構造を記述しており、基板レベルのネットリストおよびベクトルと組み合わせて初めて実際のカバレッジを定義できます。OpenOCD:バウンダリスキャンの概要およびツールサポート

Microchip:TAP 状態機械

シフトしたビットはいつ有効になる?

リセットから TMS=0,1,0,0 で取り込みを終え Shift-DR に達する。以後は Shift-DR を離れる TMS=1 の周期も含め、TCK ごとにシフトする。Pause-DR に留まっても更新値は変わらず、Update-DR で確定する。入力は自由に選べ、寄り道、停止、再同期も試せる。TMS=1 を 5 回続けると TAP がリセットに戻るが、CPU リセットやチップ内データの消去とは異なる。

図を準備しています
シフトしたビットはいつ有効になる?

シフトと更新は別の TAP 状態。Shift-DR は一時ビットを変え、Update-DR で更新レジスタへ転送する。

SWD:2本のプロトコル信号以外に電気的条件がある

SWDIOは双方向データ線、SWCLKはクロックです。要求にはアクセス方向やDP/APなどの情報が含まれ、リンクには応答、データ、パリティ、および双方向切替フェーズが必要です。Armデバッグアーキテクチャを例にとると、DPは外部デバッグエントリを提供し、APは対応する内部リソースにアクセスします。具体的なコア、マルチコア、およびバス能力は実装によって決定されます。Arm Debug Interface アーキテクチャ

「2本線だけでよい」というのはプロトコル信号のみをカウントしたものであり、基板レベルでは通常、GND、目標電圧参照が必要であり、信頼性の高いリセット/リカバリのためにnRESETを確保する価値がよくあります。SWOはオプションのトレース出力であり、SWD通常の通信に必要な第3のデータ線ではありません。また、SWDはJTAGのバウンダリスキャン機能を一般的に代替できるわけではありません。

VTrefは通常、プローブがターゲットI/Oのレベリングを検知できるようにするためのものであり、⁠ターゲットに電力を供給する出力ではありません⁠。プローブが別途給電機能を提供する場合でも、インターフェース定義に従って使用し、基板電源との競合を避ける必要があります。短い配線と適切なリターンパスは信号品質に役立ちます。SWDIOは双方向駆動を許可する必要があり、単方向バッファを安易に追加してはいけません。SEGGER VTref 定義

GDBからFlashへ:中間にはどのような責任があるか

GDB + 正しいELFシンボル、ブレークポイント、変数デバッグサービスOpenOCD / ベンダーサービスプローブターゲットレベリングと伝送ターゲットのデバッグ・メモリ認証、電源ドメイン、コア、FlashコントローラSWD / JTAGFlash 書込み方式・デバイス設定正しいアドレス、消去粒度、動作RAMデバッグリクエストは多層を通過する:プローブ接続の成功はFlashプログラマビリティを意味しない一時停止、リセット、Flash書き込みはすべてターゲット状態を変更します。現場のトラブルシューティングでは、まず必要な障害証拠を保存してください。

GDBは一致するELFを使用してアドレスとデバッグ情報を取得し、リモートプロトコルを介してOpenOCDなどのサービスにリクエストを送信します。サービスはプローブとターゲット設定を組み合わせてチップにアクセスします。プローブがSWDをサポートしていても、それがソフトウェア的に新しいMCUのFlashコントローラ、セキュリティモード、またはマルチコアトポロジをサポートしていることを意味するわけではありません。

Flashへの書き込みには、デバイスアルゴリズムが必要になることが多く、場合によっては小さなプログラムをターゲットRAMに配置して実行します。RAMの利用可能性、Flashのサイズとバンク、クロックの初期化、およびアドレスマッピングのエラーは、「IDは読み込めるが書き込めない」という状況を引き起こす可能性があります。J-Link、CMSIS-DAP、ST-Linkなども、ブランドだけで機能が同じではありません。具体的なプローブモデル、ファームウェア、ホストソフトウェア、およびターゲットサポートを一緒に照合する必要があります。「無制限のFlashブレークポイント」も条件付きのソフトウェア機能であり、すべてのプローブの一般的なハードウェアコンパレータが無制限にあるわけではありません。

以下に、OpenOCDのST-Linkインターフェース設定とSTM32F4ターゲット設定の例を示します。これは、照合済みのハードウェアおよびツールバージョンにのみ適用されます。コマンドはデバッグセッションを確立します。ここで、リセットと一時停止はターゲットの実行状態を変更するため、現場の障害を調査する際はまず必要な情報を保存してください。

openocd -f interface/stlink.cfg -f target/stm32f4x.cfg

別のターミナルでターゲットアーキテクチャをサポートするGDBを起動し、ターゲットファームウェアに対応するELFをロードします。

arm-none-eabi-gdb firmware.elf
target extended-remote localhost:3333
monitor reset halt
info registers
x/8i $pc

ここでは自動消去やアンロックコマンドは提供されていません。reset halt の実際の効果はターゲットのリセット設定に依存し、ポートも設定可能です。ローカルのOpenOCDドキュメントとターゲット設定に合わせて照合してください。OpenOCD:GDB接続とデバッグ、リセット設定

ハードウェアブレークポイント/ウォッチポイントの数は限られています。ソフトウェアブレークポイントは命令の修正が必要になることがあり、Flashでの実装はツールのサポートによって決定されます。CPUを一時停止した後、周辺デバイス、DMA、ウォッチドッグタイマ、または別のコアが一緒に一時停止されるとは限りません。ステップ実行による観察自体がタイミングを変更するため、これに基づいてリアルタイム実行に競合がないと直接証明することはできません。

ROM、USB DFU、UF2、UART は異なる分類次元に属する

ROMダウンロードエントリポイントチップにハードコード化;インターフェースと進入条件は正確なモデルで確認Flashブートローダー更新可能なソフトウェア;完全性とリカバリ設計が必要アプリケーション内アップグレードサービスアプリケーションまたは独立したサービスが実行されている必要があるダウンロードエントリポイントは、アプリケーション破損後にどの層に依存できるかを決定する図は依存関係の階層を示しており、すべてのチップがこれら3層で起動するわけではありません。USB DFU、UF2、UARTは異なるプロトコル/伝送を記述しています。

ROMはコードの配置場所を指し、DFUはファームウェアアップグレードプロトコルの名称であり、UART/USBは伝送関連のインターフェース、UF2はイメージブロック形式および一般的なロード方法を指します。USB DFUはROMまたは更新可能なブートローダーによって実装できます。USB端子を持つチップすべてに、工場出荷時にDFUが備わっているわけではありません。

プラットフォーム例照合可能な実際の動作一般化できない結論
STM32 システムメモリダウンロード具体的なモデルの起動モード、インターフェース、およびピンはAN2606を参照BOOT0をすべてハイにすればUSART1 + USB DFUが有効になるわけではない
RP2040 Pico BOOTSELROMエントリは仮想USB大容量ストレージとして表示され、UF2を受信可能UF2のドラッグ&ドロップはUSB DFUクラスプロトコルではない
nRF52 ソフトウェアDFU一般的なソリューションは、書き込まれた対応ブートローダーに依存全シリーズにUSB ROM DFUが工場出荷時に搭載されているわけではない
AVR / PIC プログラミングインターフェースはデバイスとツールに応じて選択ISP、ICSP、UPDI はすべてAVRの6ピンで同じプロトコルではない

STM32のエントリポイントは、オプションバイト、チップのリビジョン、およびセキュリティ設定の影響を受ける可能性があり、正確な品番で表を参照する必要があります。ST AN2606

PicoのBOOTSELコードはROMに位置しており、アプリケーションFlashが破損しても、このROMが上書きされることは通常ありません。ただし、正常な電源供給、USB接続、およびデバイスの状態に依存します。Raspberry Pi Pico ドキュメント

NordicのnRF5 SDK DFUツールは、対応するソフトウェアブートローダーを要求します。新しいソフトウェアプラットフォームでも、使用するアップグレードソリューションに合わせて設定する必要があります。特定の開発ボードにプリインストールされている機能を、すべてのブートチップに帰属させてはいけません。Nordic nRF Device Firmware Update

Microchipのいくつかの新しいAVRは、プログラミングとデバッグにUPDIを使用し、PICのICSPには独自のデバイスプロトコルと進入条件があります。Microchip AVR インターフェース

ダウンロード時間には、消去、検証、および伝送を分けて考慮する

UART 115200ボー、8N1の場合、1バイトあたり10ビットが必要であり、理想的な純粋バイト率は11520 B/sです。256 KiBのイメージの場合、データ伝送だけでも少なくとも約22.76秒かかり、プロトコルヘッダ、応答、再試行、Flashの消去/書き込み、および検証が加わります。シリアルボーレートを上げても、内部消去/書き込みに支配される時間は比例して短縮されず、USB接続だからといってUSBの公称バス帯域幅で書き込みが完了するわけではありません。

イメージアドレス、ベクタテーブル/エントリ、リンクレイアウト、ブートローダーパーティション、および署名要件は一致している必要があります。ツールが書き込み完了を報告した後でも、バイト検証の通過、起動検証の通過、およびアプリケーション機能の通過を区別する必要があります。これら3つは同じ結果ではありません。

接続できない場合、依存関係が最も少ない層から段階的に確認する

まず、ターゲット電源、VTref、GND、インターフェース方向、リセット状態、およびホストによるプローブの認識を照合し、次に伝送選択、ターゲット設定、およびクロックを照合します。デバッグレートを下げると接続品質の判断に役立ちますが、誤った電圧やセキュリティロックは修復できません。

アプリケーションが起動後にデバッグピンを無効にするか、低消費電力モードに入った場合、チップのサポートに応じてリセット時に接続を試みることができます。これにはリセット線と正しいツール設定が必要であり、すべてのデバイスが同じフローをサポートしているわけではありません。読み込み保護、認証、および永続的なセキュリティ状態は、ベンダーの定義に従って処理する必要があります。一部のリカバリはデータを消去し、一部の状態は不可逆的であるため、「アンロック/チップ全体消去」を障害証拠を保存する前のデフォルトアクションとして扱ってはいけません。

一時停止できるようになったら、まずELFが実行中のイメージと一致していることを確認し、次にリセット原因、PC、スタック、および例外コンテキストを確認します。ソースファイルが同じであるだけでは不十分で、最適化、リンクアドレス、ライブラリ、または生成設定が異なると、変数や行番号が誤った判断を招くことがあります。

バストラブルシューティングでは、ロジックアナライザとオシロスコープを組み合わせます。1回のACKは、あるバイトが受信されたことを示すだけで、データが新鮮であること、後続のトランザクション、または電気的マージンが常に正しいことを証明するものではありません。プロトコルデコードが正常であっても、必要に応じて電圧、立ち上がりエッジ、および電源をチェックする必要があります。ロジックアナライザだけでは、すべての物理層の問題を排除できません。

開発、生産ライン、および現場はターゲットに応じてプロセスを整理する

開発段階では、観測可能性とリカバリエントリポイントが必要です。生産ラインでは、追跡可能なイメージ、検証、シリアライズ、および機能テストが必要です。現場でのアップグレードでは、検証、互換性、および電源断からの復旧が必要です。量産では、専用のプログラマを使用してバッチ書き込みを行うことも、確立されたダウンロードサービスを使用することもでき、「まずSWDでブートローダーを書き込み、次にDFU」と固定する必要はありません。

OTAは、イメージが無線またはネットワークを介して到達したことを示すだけで、真正性と信頼性の高い切り替えを自動的に提供するものではありません。受信、検証、候補領域への書き込み、起動確認、および失敗時のリカバリは、明確な状態機械を形成する必要があります。読み込み保護、署名、およびデバッグ権限は異なるメカニズムであり、最終的な設定は製品の保守ポリシーと一致している必要があります。

伝送の下限を再計算する

from math import isclose
baud, bits_per_byte, image_bytes = 115200, 10, 256*1024
payload_rate = baud/bits_per_byte
assert payload_rate == 11520
assert isclose(image_bytes/payload_rate, 22.755555555555556)
assert isclose(image_bytes*8/1e6, 2.097152)
print('UART 8N1 の有効バイト率およびイメージ純粋伝送時間の下限チェック通過')

伝送時間は書込み経路の下限にすぎません。書込み内容、起動、実際の機能の検証結果はそれぞれ記録します。

続きの参照