組み込みLINUXシステム用の静的/動的統合デバッグモード

既存の組み込みLINUXシステムの開発プロセスでは、すべてのエンジニアは2つの異なるデバッグモードを使用してシステムのカーネルとアプリケーションを別々にデバッグするのにうんざりしています。まず、JTAGデバッグツールを使用してLINUXシステムを設定して起動し、組み込みLINUXシステムが正常に実行されたら、GDBを介してデバッグを続行する必要があります。

LAUTERBACHはこれら2つの伝統的なデバッグ技術を組み合わせて新しいLINUXデバッグ技術を提供します。

この記事では、これら3つの異なるデバッグモードの実装と適用を詳細に紹介し比較するための例として、ARMアーキテクチャ上のLINUXシステムの開発を取り上げます。

静的デバッグモード

JTAGデバッグインタフェースを介したソフトウェアデバッグ用ツールは、静的デバッグモードでのみ機能しますプロセッサとシステム全体の両方を同時に一時停止する必要があります。その後、デバッグツールはJTAGインタフェースを介してプロセッサとターゲットシステムの現在の状態を取得して表示します（図1を参照）。

静的デバッグモードは、次のような利点があります

静的デバッグモードのみの環境ニーズは、ターゲットシステムで標準のJTAGデバッグをサポートしている必要があり、最大の利点のデバッグモードは、我々がリセットからサポートすることができるということですベクタテーブルのデバッグを開始;限り、デバッグツールとして

とLINUX MMUのデバッグをサポートし、デバッグには、Linuxカーネルやプロセスなど、国境を越えた問題に達成することができ、ソフトウェアに異常がある場合
は、

、あなたは常にプロセッサを掛けることができますエラーコードとシステムのステータスを確認してください。

プロセッサはサスペンド状態にあるため、カーネルや他のプロセスがシステムに干渉することはありません。

ただし、静的デバッグモードには欠点があり、プロセッサが一時停止されると、すべての通信インタフェースプロセスが同時に終了します。その結果、Ethernet、Bluetooth、CANなどのインターフェイスを介してプロセッサと通信するすべての外部デバイスは、応答タイムアウトを待つために切断されます。そのため、スタティックモードでデバッグする場合、1つのプロセスまたは機能だけをデバッグしても、システム全体の状態と構成を変更してからプログラムの実行とデバッグを続けると、システムの整合性と継続性が保証されません。その後のデバッグは意味がないかもしれません。

動的デバッグモード

GDBデバッグモードは、組み込みLINUXシステム用の汎用動的デバッグモードです。このモードでは、現在のプロセスだけを中断することが可能で、システムのカーネルと他のすべてのプロセスは実行され続けます。

ただし、GDBは純粋なソフトウェアデバッグツールであり、次のソフトウェア環境が必要です。

ターゲットシステムにアクティブなGDBサーバーLINUXプロセスが存在する必要があります。

ホスト端部は、TRACE32（図2）
ログイン

RS232またはイーサネット通信インタフェースを介して状態TRACE32 GDBサーバは、収集プロセスが現在中断されているように、対応するデバッグソフトウェアを有します。ただし、動的デバッグモードを実装するには、次の2つの条件に基づいている必要があります。

ターゲットシステムは正しく初期化され、正しく起動されています。

GDBサーバーは常にアクティブです。ステータス - つまり、通信インターフェイスが正しく実行され、プロセッサまたはGDBサーバーが他のプログラムエラーによって中断されることはありません。要約すると、どちらのデバッグモードにも長所と短所があります。静的デバッグモードは実装が比較的簡単で、操作は比較的単純ですが、システムの継続性と整合性は保証されず、動的デバッグモード環境はより複雑な環境を必要とします。したがって、LAUTERBACHは、上記の2つのデバッグモードを実装し、それぞれの長所を最大限に活用しながらそれぞれの欠点を完全に克服し、組み込みLINUXデバッグテクノロジの飛躍を実現できるデバッグツールを提供します。

統合静的および動的デバッグモード

組み込みLINUXシステムの場合、統合静的および動的デバッグモードをサポートするTRACE32デバッグツールは、次のように機能します（図3を参照）。

1. TRACE32デバッグツールはJTAGインタフェースを介してスタティックデバッグモードに入ります。スタティックモードでは、まずターゲットシステムハードウェアおよびダイナミックデバッグモード（GDB）の環境設定が完了します。
2.ターゲットシステムの初期化および起動プログラムがデバッグの中心である場合は、静的デバッグモードを使用してデバッグします。

3.ターゲットシステムが正しく起動したら、アプリケーションの動的デバッグのためにTRACE32を動的デバッグモードに切り替えることができます。

4.動的デバッグ中の場合は、システムを再設定して初期化する必要があります。 TRACE32は、いつでもシステムを静的デバッグモードに切り替えることもサポートしています。

同時に、統合された静的および動的デバッグモードの実装により、以下の新しいプロパティの多くも動的デバッグモードに追加されました。

ARMアーキテクチャベースのプロセッサの場合、動的デバッグモードの情報通信インタフェースとしてデバッグ通信チャネル（DCC）を使用できます。これには、統合されたスタティックおよびダイナミックデバッグモードをサポートするためのJTAGインターフェイスが1つだけ必要です。

2つ以上のプロセスを同時にデバッグします。

通信インタフェースとしてのDCCの使用

ARMアーキテクチャでは、DCC通信インタフェースはすでにJTAGインタフェースに含まれています。アプリケーションがターゲットプロセッサ上で実行されている場合、DCCを介して次の2つのモジュール間情報通信を実装することは完全に実現可能です。

ホスト側のデバッグソフトウェア

ターゲットシステム上のGDBサーバー経由のすべてのアプリケーション

したがって、TRACE32がGDBサーバーとの通信用のインターフェイスとしてDCCを使用する場合、動的デバッグモードをサポートするには、追加の通信インターフェイスが必要です（図4を参照）。

実際のデバッグプロセスで同じ時間

でのデバッグ複数のプロセスは、多くの場合、同時に複数のプロセスをデバッグする必要があります。このプロパティを実装するために、LAUTERBACHは動的デバッグモード用のT32Serverモジュールを提供します。 T32ServerがターミナルウィンドウからLINUXプロセスとして起動されている場合は、次のコマンドと操作を実行できます。

プロセスの開始（TASK.RUN）

プロセスの実行（TASK.SELECT）の選択プロセスが開始され、チェックされている場合

プロセスを停止（TASK.KILL）

、T32Serverは、プロセスごとに別々のGDBサーバーが割り当てられます（図5に示すように）上記の3つのTASK操作コマンドを使用すると、複数のプロセスを同時に変調することができます。ユーザーはコマンド（TASK.LIST）を使用して現在のプロセス情報を表示できます。