(57)【要約】中央処理ユニットと、トレースモジュールを含むデバッグ回路と、内部クロック信号を提供するためのシステムクロックモジュールと、デバッグモードの間、システムクロックモジュールがリセット信号を受信することを防止するリセット検出ユニットとを有する、デバッグ能力を伴うプロセッサデバイス。一実施形態において、トレースモジュールは、リセット信号が検出された後、トレース情報を記録するように動作可能であり、トレース情報を記録した後、システムクロックモジュールをリセットする信号を生成する。
2015516637.tif 000002
【特許請求の範囲】
【請求項１】
デバッグ能力を有するプロセッサデバイスであって、
中央処理ユニットと、
ソーストレースモジュールを含むデバッグ回路と、
内部クロック信号を提供するためのシステムクロックモジュールと、
デバッグモードの間、前記システムクロックモジュールがリセット信号を受信することを防止するリセット検出ユニットと
を備えている、プロセッサデバイス。
【請求項２】
前記トレースモジュールは、リセット信号が検出された後、トレース情報を記録するように動作可能であり、前記トレース情報を記録した後、前記システムクロックモジュールをリセットする信号を生成する、請求項１に記載のプロセッサデバイス。
【請求項３】
前記トレース情報は、リセットソース情報を含む、請求項２に記載のプロセッサデバイス。
【請求項４】
前記トレースモジュールは、実行された命令に関する情報を含むトレースストリームを生成し、前記トレースストリームは、外部インターフェースを通して出力される、請求項１に記載のプロセッサデバイス。
【請求項５】
前記トレースストリームは、パケットベースである、請求項４に記載のプロセッサデバイス。
【請求項６】
前記トレースパケットは、トリガソースに関する情報を含む、請求項５に記載のプロセッサデバイス。
【請求項７】
前記情報は、条件付きで提供され、前記条件は、ユーザ定義されることができる、請求項６に記載のプロセッサデバイス。
【請求項８】
リセット信号は、同期リセット信号または非同期リセット信号であることができる、請求項１に記載のプロセッサデバイス。
【請求項９】
同期リセット信号は、ウォッチドッグタイマＷＤＴ、前記中央処理ユニットによって実行されるＲＥＳＥＴ命令、スタックオーバーフロー／アンダーフローリセットによって生成される、請求項８に記載のプロセッサデバイス。
【請求項１０】
非同期リセット信号は、前記プロセッサデバイスの外部ピンを通して受信される、請求項８に記載のプロセッサデバイス。
【請求項１１】
プロセッサデバイス内で実行されたコードをデバッグする方法であって、
中央処理ユニット（ＣＰＵ）によってコードを実行することと、
リセットの決定に応じて、システムクロックモジュールを除く、前記マイクロコントローラの内部ユニットにリセット信号を自動転送することにより、トレースモジュールのさらなる動作を可能にすることと、
前記リセットの受信後、トレース情報を記録することと
を含む、方法。
【請求項１２】
前記トレース情報が記録された後、前記システムクロックモジュールをリセットすることをさらに含む、請求項１１に記載の方法。
【請求項１３】
前記トレース情報は、リセットソース情報を含む、請求項１２に記載の方法。
【請求項１４】
前記トレースモジュールは、実行された命令に関する情報を含むトレースストリームを生成し、前記トレースストリームは、前記外部インターフェースを通して出力される、請求項１１に記載の方法。
【請求項１５】
前記トレースストリームは、パケットベースである、請求項１４に記載の方法。
【請求項１６】
前記トレースパケットは、トリガソースに関する情報を含む、請求項１５に記載の方法。
【請求項１７】
前記情報は、条件付きで提供され、前記条件は、ユーザ定義されることができる、請求項１６に記載の方法。
【請求項１８】
リセット信号は、同期リセット信号または非同期リセット信号であることができる、請求項１１に記載の方法。
【請求項１９】
同期リセット信号は、ウォッチドッグタイマＷＤＴ、前記中央処理ユニットによって実行されるＲＥＳＥＴ命令、スタックオーバーフロー／アンダーフローリセットによって生成される、請求項１８に記載の方法。
【請求項２０】
非同期リセット信号は、前記プロセッサデバイスの外部ピンを通して受信される、請求項１８に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
（関連出願の引用）
本願は、米国仮特許出願第６１／６４３，７２５号（２０１２年５月７日出願、名称「ＰＲＯＣＥＳＳＯＲ  ＤＥＶＩＣＥ  ＷＩＴＨ  ＩＮＳＴＲＵＣＴＩＯＮ  ＴＲＡＣＥ  ＣＡＰＡＢＩＬＩＴＩＥＳ」）の利益を主張し、該出願は、その全体が本明細書に引用される。
【０００２】
（技術分野）
本開示は、プロセッサデバイスに関し、特に、統合されたデバッグ能力を伴う、マイクロコントローラデバイスに関する。
【背景技術】
【０００３】
現代のマイクロプロセッサおよびマイクロコントローラは、いわゆる回路内デバッガまたはエミュレータデバイスを用いて、起動中のプログラムを分析することを効率的に可能にする回路を含む。この目的を達成するために、マイクロコントローラまたはマイクロプロセッサは、例えば、デバッグインターフェースとして動作するように、デバイスの複数の機能ピンをプログラムすることによってアクティブ化されることができるデバッグ機能および特定のインターフェースをサポートする内部回路を提供する。そのようなインターフェースは、通常、高速シリアルインターフェースとして、実際のデバイスと外部デバッガまたはエミュレータとの間の高速通信を可能にするように構成されることができる。したがって、デバイス自体は、このインターフェース、および他の目的のために使用されることができる関連付けられたピンをアクティブ化させない通常動作モードと、このインターフェースを使用して、外部ホストコンピュータからおよびそれによって動作され得る、デバッガまたはエミュレータ等のそれぞれの外部デバイスとデータを交換するデバッグ動作モードとにおいて動作されることができる。デバッガまたはエミュレータはまた、プログラマとして動作されることができ、プログラムは、同一のデバッグインターフェースを介して、標的デバイスに転送される。ホストコンピュータ、外部デバッガ、またはエミュレータは、したがって、安価な分析およびデバッグシステムを形成する。
【０００４】
現代のプロセッサおよびマイクロコントローラは、それぞれのデバイスの内側に拡張された一式のデバッグ機能を提供する。例えば、いくつかのブレークポイントが、デバイス内に設定され、デバイスが、実際に、リアルタイムで起動することを可能にすることができ、これは、高速シリアルインターフェースだけを使用するとき、外部デバッガでは不可能であり、したがって、ボンドアウトチップおよび高価なデバッグ回路を要求するであろう。しかしながら、これらの内部デバッグ回路網の機能性は、限定されたシリコン専有面積および他の理由のため、必然的に、幾分、制限される。例えば、トレースバック機能は、多くの場合、外部回路内デバッガによってサポートされず、さらにより複雑な回路内エミュレータは、デバッグモードにあるとき、特に、デバイスが、リセットを実行するとき、トレース機能を十分にサポートしない場合がある。
【発明の概要】
【課題を解決するための手段】
【０００５】
したがって、プロセッサまたはマイクロコントローラデバイス内の改良された回路内デバッグユニットの必要性が、存在する。例えば、非同期および同期リセットの両方を通した命令トレースが、種々の実施形態によって、可能にされる。
【０００６】
ある実施形態によると、デバッグ能力を有するプロセッサデバイスは、中央処理ユニットと、トレースモジュールを含むデバッグ回路と、内部クロック信号を提供するためのシステムクロックモジュールと、デバッグモードの間、システムクロックモジュールがリセット信号を受信することを防止するリセット検出ユニットとを備え得る。
【０００７】
さらなる実施形態によると、トレースモジュールは、リセット信号が検出された後、トレース情報を記録し、トレース情報を記録した後、システムクロックモジュールをリセットする信号を生成するように動作可能であることができる。さらなる実施形態によると、トレース情報は、リセットソース情報を含み得る。さらなる実施形態によると、トレースモジュールは、実行された命令に関する情報を含むトレースストリームを生成し得、トレースストリームは、外部インターフェースを通して出力される。さらなる実施形態によると、トレースストリームは、パケットベースであることができる。さらなる実施形態によると、トレースパケットは、トリガソースに関する情報を含み得る。さらなる実施形態によると、情報は、条件付きで提供されることができ、条件は、ユーザ定義されることができる。さらなる実施形態によると、リセット信号は、同期リセット信号または非同期リセット信号であることができる。さらなる実施形態によると、同期リセット信号は、ウォッチドッグタイマＷＤＴ、中央処理ユニットによって実行されるＲＥＳＥＴ命令、スタックオーバーフロー／アンダーフローリセットによって生成されることができる。さらなる実施形態によると、非同期リセット信号は、プロセッサデバイスの外部ピンを通して受信されることができる。
【０００８】
別の実施形態によると、プロセッサデバイス内で実行されるコードをデバッグする方法は、中央処理ユニット（ＣＰＵ）によってコードを実行することと、リセットの決定に応じて、システムクロックモジュールを除く、マイクロコントローラの内部ユニットにリセット信号を自動転送することにより、トレースモジュールのさらなる動作を可能にすることと、リセットの受信後、トレース情報を記録することとを含み得る。
【０００９】
本方法のさらなる実施形態によると、本方法はさらに、トレース情報が記録された後、システムクロックモジュールをリセットすることを含み得る。本方法のさらなる実施形態によると、トレース情報は、リセットソース情報を含み得る。本方法のさらなる実施形態によると、トレースモジュールは、実行された命令に関する情報を含むトレースストリームを生成し得、トレースストリームは、外部インターフェースを通して出力される。本方法のさらなる実施形態によると、トレースストリームは、パケットベースであることができる。本方法のさらなる実施形態によると、トレースパケットは、トリガソースに関する情報を含み得る。本方法のさらなる実施形態によると、情報は、条件付きで提供されることができ、条件は、ユーザ定義されることができる。本方法のさらなる実施形態によると、リセット信号は、同期リセット信号または非同期リセット信号であることができる。本方法のさらなる実施形態によると、同期リセット信号は、ウォッチドッグタイマＷＤＴ、中央処理ユニットによって実行されるＲＥＳＥＴ命令、スタックオーバーフロー／アンダーフローリセットによって生成されることができる。本方法のさらなる実施形態によると、非同期リセット信号は、プロセッサデバイスの外部ピンを通して受信されることができる。
【図面の簡単な説明】
【００１０】
【図１】図１は、種々の実施形態による、統合されたデバッグモジュールのブロック図を示す。
【図２】図２は、図１のハードウェアブレークポイントブロック図をより詳細に示す。
【図３】図３は、図１のイベントコンバイナブロック図をより詳細に示す。
【図４】図４は、トレースクロックを取り扱うためのブロック図を示す。
【図５】図５は、図４において使用されるような例示的トレースＱ−ジェネレータを示す。
【図６】図６は、図４において使用されるような例示的ＩＣＤアナログリセットユニットをより詳細に示す。
【図７】図７は、図１のトレースブロック図をより詳細に示す。
【図８】図８は、典型的トレース信号タイミング図を示す。
【図９】図９は、簡略化されたブロック図のトレースサブシステムを示す。
【図１０】図１０は、種々の実施形態による、内蔵デバッグユニットを伴うマイクロコントローラと、外部回路内デバッグ（ＩＣＤ）コントローラとを使用するシステムのブロック図を示す。
【図１１】図１１は、システムクロックｃｌｋｉｎおよび関連直交信号の例示的タイミング図を示す。
【図１２】図１２は、種々の実施形態による、内蔵デバッグユニットを伴う、マイクロコントローラと、外部回路内デバッグ（ＩＣＤ）コントローラとを使用する、システムのブロック図を示す。
【発明を実施するための形態】
【００１１】
典型的マイクロコントローラデバイスは、いくつかの非同期および同期システムリセットソースを有し得る。マイクロコントローラユニット（ＭＣＵ）システムが、種々の実施形態に従って、そのようなリセットの発生に応じて、動作を停止しても、デバイスのデバッグユニット内の命令トレースモジュールは、リセット発生およびソースを記録するであろう。この目的を達成するために、種々の実施形態は、外部非同期および内部同期デバイスリセットを通して、命令トレースを提供する。
【００１２】
種々の実施形態によると、トレースシステムは、システムクロック構成モジュールに対するリセットをブロックし、リセットを同期させ（非同期である場合）、リセットを記録する。システムは、したがって、リセットに対するタイミング感度を有していない。
【００１３】
図１は、ある実施形態による、マイクロコントローラ内に統合され得る回路内デバッグモジュールのブロック図を示す。しかしながら、前述のような一般的概念は、他のタイプのオンチップデバッグ回路内に実装されることもできる。ブロック図は、例えば、マイクロコントローラ内に実装されることができ、以下の５つの基本ブロックから成り得るモジュールを示す。
・ブレークポイント比較論理１３５
・ストップウォッチサイクルカウンタ論理１５０
・制御および状態機械論理１４５
・トレース論理１２０
・イベントコンバイナ論理１２５
ＣＰＵ１１０は、内部バスを通して、ハードウェアブレークポイントユニット１３５と、イベント検出ユニット１４０と、制御論理ユニット１４５と、バックグラウンドインターフェース１５５とに連結される。マルチプレクサ１６０は、専用デバッグクロックおよびデータピン１６５を通して、外部デバッガとのデバッグユニットの連結を可能にするために使用される。制御論理１４５は、１つ以上の外部ピンと連結され得る。図１は、例示的ＴＲＧＩＮピン１８５を示す。そのようなピンは、他の機能を伴わない専用ピンであり得る。しかしながら、特に、低ピンデバイスでは、そのようなピンは、プログラム制御下、異なる周辺デバイスに割り当てられることができ、したがって、そのプログラムされた割当に従って、異なる機能を行うことができるマルチ機能ピンであり得る。例えば、そのようなピンは、構成レジスタを用いて、トレーストリガ入力機能に加え、シリアルインターフェースクロックピン、デジタルＩ／Ｏピン、アナログ入力ピン等として作用するようにプログラムされ得る。図１に示されるように、制御論理はまた、ピン１８５と同様に、マルチ機能ピンであり得るトリガ出力ピン１９０を提供する。トレースモジュール１２０は、トレース機能停止入力ピン１１５と、トレースクロックおよびデータ出力ピン１７５と連結される。図１はまた、制御論理１４５を通して構成可能であり得る、パルス除去フィルタ１７０および１８０を示す。そのようなフィルタを通した信号ルーティングは、図１には示されない。いくつかの実施形態によると、ブレークポイントデバッグは、命令が実行される前に、実行が一時停止されるように実装される（いわゆる「ゼロスキッド」動作）。他のデバッガ実施形態によると、これは、該当せず、コードが、停止または「スキッド」し、プロセッサが一時停止される前に、命令が実行することを可能にする場合、問題を生じさせ得る。外部イベントは、（定義上）命令実行ストリームと非同期である。したがって、その動作は、ゼロスキッド概念に匹敵しない。
【００１４】
内部信号ｄｅｂｕｇ＿ｅｎ＝１であるとき、モジュールは、イネーブルにされ、全「一時停止」イベントを監視し、イベントを生成し、データ捕捉等を行う。内部信号ｄｅｂｕｇ＿ｅｎ＝０である場合、全デバッグ論理は、ディスエーブルにされ、モジュールは、最小電力モードを消費するように構成される。
【００１５】
低侵襲性デバッグを行うために、データをデバイスからリアルタイムでストリーミングする手段を有することが有用であり得る。トレースモジュール１２０は、読み取られる、または特定のアドレスに書き込まれるデータを取り出し、それをトレースポートから伝送する方法をサポートする。これは、リアルタイムウォッチポイントとして説明されることができる。デバイスの通常動作は、ウォッチポイントを使用するとき、インタラプトされない。
【００１６】
データ捕捉は、ハードウェアブレークポイントを生成するために使用されるものと同一のハードウェアを使用して行われ得る。一時停止を生成することと同時のデータ捕捉のためにブレークポイントを使用することは、両動作が生じることを可能にするであろう。しかしながら、データ捕捉およびデータマッチングを同時にイネーブルにすることは、特に、２以上のブレークポイントカウントに対して、予想外の結果を生成し得る。データ捕捉およびデータ比較は、同一の物理的レジスタを使用するので、比較値は、捕捉毎に更新されるであろう。
【００１７】
図２は、ハードウェアブレークポイントユニット１３５をより詳細に示す。ハードウェアブレークポイントは、プログラムまたはデータメモリのいずれか内のアドレスをマッチングすることにおいてブレークするように構成されることができる。この目的を達成するために、それぞれのコンパレータ２２０および２３０とデコーディングユニット２４０とが、図２に示されるように、提供される。ブレークポイントが、データメモリ上で動作するように選択されると、ブレークポイントは、加えて、データ値およびマスクを伴って認定され、ある値のみがブレークポイントイベントを生成することを可能にすることができる。データブレークポイントはまた、随意に、読み取りまたは書き込みサイクルにおいてのみブレークするように設定されることができる。あらゆる場合において、ブレークポイントは、ブレークポイントイベントが生成される前に、特定のイベントが、Ｎ回、生じなければならないようなカウンタ２１０を有する。これは、例えば、いくつかの実施形態によると、１〜２５６回の任意の値に設定されることができる。
【００１８】
図２のブロック図は、単一ブレークポイントに関して示される。しかしながら、実装されるブレークポイントの数は、種々の実施形態に従って、可変であり、多くのブレークポイントが、存在し得る。図２は、種々のパラメータが、ブレークポイントのためのトリガ要件を定義するようにプログラムされることができる、例示的実施形態を示す。他の実施形態によると、より少ないまたはより多いそのようなパラメータが、使用され得る。例えば、ブレークポイントを生成するために必要なブレークポイント発生数は、カウンタ２１０内のＢＰｘＣＮＴパラメータによって設定されることができる。各ブレークポイントモジュールは、同じレジスタを有し得る。
【００１９】
ブレークポイントは、イベントチャネル定義の中にリストされ、サイクルカウンタ１５０を開始または停止するために、イベントコンバイナステージ１２５を設定またはリセットするために、トレースユニット１２０を開始または停止するために、あるいはスタックスナップショットを撮影するために使用されることができる。
【００２０】
一実施形態によると、ブレークポイントがイネーブルにされるために、制御レジスタＩＣＤＢＰｘＣＯＮのビットＢＰＥＮが、設定されなければならない。このビットが、消去される場合、この特定のブレークポイントに対する全回路は、ディスエーブルにされ、ブレークポイントイベントは、生成されないであろう。ブレークポイントは、認定条件のＮ回目の発生毎にのみ、アクションをトリガするように構成されることができる。例えば、３回目の発生毎にトリガするようにブレークポイントを設定するために、カウンタ２１０は、ＢＰｘＣＮＴ＝２に設定される。それぞれの制御レジスタが、その値をリロードし、および／または現在の状態を監視するために、カウンタ２１０と組み合わせて使用され得る。
【００２１】
ブレークポイントはまた、例えば、関連付けられた構成レジスタ内にそれぞれのビットを設定することによって、実行コンテキスト（メインラインコード、インタラプトハンドラ、または両方）に基づいて認定され得る。ブレークポイントは、したがって、プログラムが選択されたコンテキストから実行するときのみ、生じ得る。
【００２２】
さらに別のブレークポイントパラメータは、構成レジスタ内に、プログラムカウンタ（ＰＣ実行アドレス）を監視することを可能にする、それぞれのビットを設定することによって設定され得る。プログラムメモリブレークは、ゼロスキッドであり、動作が実行される前に生じる。ＰＣは、トリガ命令のアドレスを示すであろう。
【００２３】
それぞれの制御ビットが、消去されている、例えば、ＢＰＡＲＥＮ＝‘０’であるとき、ＰＣが所定のアドレスに等しくなると、ブレークがトリガされる。ＢＰＡＲＥＮ＝‘１’であるとき、ＰＣがアドレスの所定の包含範囲内にあると、ブレークがトリガされる。
【００２４】
いくつかの実施形態によると、実行されている命令のみ、ブレークポイントを生成することができる。ＰＣが、実行されていないアドレスにあるとき、ブレークポイントは、トリガしない。これは、以下を含む。
・フロー変更命令（ＣＡＬＬ、ＲＥＴＵＲＮ等）、
・スキップされた命令（ＢＴＦＳＳ、ＢＴＦＳＣに従って）、または
・ＰＣＬ、ＦＳＲ、または他の２つのサイクル命令後の次のフェッチ。
【００２５】
別の制御ビットフィールドが、制御レジスタ内で０１、１０、または１１に設定されると、ブレークポイントは、データアクセス、すなわち、アドレスおよび値の両方を監視する。関連付けられたビットの３つの状態は、読み取りまたは書き込みサイクルが、ブレークポイントを決定するために使用されるかどうかを選択する。
【００２６】
データブレークポイントは、必然的に、データが読み取られた、または書き込まれた後、命令実行終了時にブレークを生じさせる（規定通りに）。あらゆる場合において、命令は、完了するまで実行する。故に、「ブレーク」は、実際には、次の命令実行時に生じ、ＰＣは、トリガ命令後に命令を示すであろう。ブレークはまた、メモリアドレスおよびデータ値認定子の両方が満たされるときにトリガされ得る。
【００２７】
サイクルカウンタ１５０は、ユーザコードがプロファイル化され得るようなストップウォッチ機能を提供するために使用されるカウンタである。サイクルカウンタは、それぞれの制御レジスタによって制御される。カウンタ１５０は、４つの８−ビットカウンタ／レジスタから成り得る。カウンタ１５０は、ＣＰＵのＱ−サイクルの終了毎にインクリメントされ得る。すなわち、マルチサイクル命令（例えば、ＧＯＴＯ）は、複数回、カウントを行う。
【００２８】
複数の機能が特定のイベントによって制御されることを可能にするために、可能なソースの全てが、１つのイベントバスに組み合わせられ得る。これは、サイクルカウンタ１５０、トレースユニット１２０、およびイベントコンバイナユニット１２５が、同一の設定を使用して、そのアクションを選択することを可能にする。
【００２９】
イベントコンバイナ３００は、図３に示されるように、複数のイベント入力３２０を監視し、それらの入力の組み合わせおよびシーケンスに基づいて、一時停止またはトリガ出力１９０を生成することができる。イベントコンバイナ３００は、対応する制御ビットが設定されると、イネーブルにされる。ディスエーブルにされたコンバイナ３００は、出力イベントをもたらさない。イベントコンバイナ３００は、イベントチャネル定義の中にリストされ、サイクルカウンタ１５０を開始または停止するために、イベントコンバイナステージ３１０を設定またはリセットするために、トレースユニット１２０を開始または停止するために、またはスタックスナップショットを撮影するために使用されることができる。イベントコンバイナステージ３１０は、そのステージに対するそれぞれの制御ビットが、関連付けられた制御レジスタ内に設定されると、独立して、イネーブルにされる。ステージの現在の出力は、関連付けられたステータスビット内に反映されるであろう。ステージ３１０は、図３に示されるような暗示される順序を有し、以下のいくつかの方法で組み合わせられることができる。
・ステージは、個々に、イベントによってアクティブ化されることができる。
・ステージは、次の下位ステージがアクティブである間、イベントによってアクティブ化されることができる。
・ステージは、個々に、イベントによって非アクティブ化されることができる。
・ステージは、イベントによって、または次の下位ステージが非アクティブ化されると、非アクティブ化されることができる。
【００３０】
それぞれの制御ビットを設定することによって、組み合わせられたイベントの（Ｎ＋１）回目の発生のみが、出力イベントを信号伝達するであろう。Ｎは、０〜２５５に設定されることができる。組み合わせられたトリガ条件が満たされる場合、レジスタは、１だけデクリメントされる。組み合わせられたトリガ条件が満たされる場合、イベントコンバイナイベントが、生成され、カウンタに、既定値をリロードされる。また、新しいカウント値がそれぞれの制御レジスタに書き込まれると、随時、カウンタ内の値が、リロードされる。例えば、３回目の発生時にトリガするようにブレークポイントを設定するために、それぞれのカウンタ値は、２に設定されるべきである。
【００３１】
加えて、いくつかの実施形態によると、ピンＴＲＧＩＮ１８５にフィードされる外部信号は、ユーザ入力が、トレースストリーム内に挿入されるべきトレースパケットを生成し、一時停止を生成し、随意に、ＴＲＧＯＵＴ信号をトリガすることを可能にする。「極性」＝０（図６）であるとき、トリガ入力は、アクティブ高であり、立ち上がりエッジがイベントを生じさせる。「極性」＝１であるとき、トリガ入力は、アクティブ低であり、立ち下がりエッジがイベントを生じさせる。別の制御ビットは、フィルタを制御するために使用され、例えば、認識されるための最小時間の間、入力がアクティブ状態でなければならないことを定義するために使用され得る。より短いパルスは、したがって、無視される。
【００３２】
ＴＲＧＩＮイベントが、イベントチャネル定義の中にリストされることができ、サイクルカウンタ１５０を開始または停止するために、イベントコンバイナステージ３１０を設定またはリセットするために、トレースユニット１２０を開始または停止するために、またはスタックスナップショットを撮影するために使用されることができる。トリガ入力の変化は、トレースがイネーブルにされている場合、トレースパケットを生成するであろう。
【００３３】
ブレークポイント等のイベントが、イネーブルにされたトリガに伴って生じると、ＴＲＧＯＵＴピン１９５上にパルスが、生成される。基本トリガ出力信号動作は、それぞれの制御ビットを設定することによって構成される。これらの制御ビットは、例えば、トリガ出力が、ほぼトリガイベントの持続時間の間、アサートされるように制御し得る。隣接したイベントまたは重複したイベントは、信号をアサートされた状態に保持し得る。制御ビットはまた、出力が最小期間まで引き伸ばされるどうか制御し得る。ＴＲＧＯＵＴワンショットがトリガされると、そのタイミング期間内に発生するさらなるイベントは、無視されるであろう。ワンショットがタイムアウトし、ＴＲＧＯＵＴがゼロに戻った後、再び、別のイベントによってトリガされ得る。ワンショットは、エッジトリガされ、イベント信号が持続する場合でも、所定の期間後、消えてなくなるであろう。
【００３４】
ソフトウェアは、それぞれの制御ビットを設定することによって、トリガ出力を生じさせ得る。デバイスが、ウェーク状態である場合、ビットは、１サイクル後、ハードウェアによって消去される。ＴＲＧＯＵＴもまた、それぞれの制御ビットを書き込むことによって、消去され得、またはデバイスがウェックアップすると、自動的に、消去されるであろう。
【００３５】
外部非同期リセットは、典型的には、プロセッサデバイス全体に影響を及ぼす。そのようなイベントが発生したことを適切に記録するために、命令トレースモジュールは、リセットのタイミングに関係なく、リセットによって影響を受けないように設計される。種々の実施形態は、したがって、オンチップデバッグ能力を向上させ、従来のマイクロコントローラデバイス上で以前は利用可能ではなかった特徴を提供する。したがって、通常、高価な専用回路内デバッガからしか知られていない高度なデバッグ能力が、「標準的」マイクロコントローラまたはマイクロプロセッサデバイス内に実装されることができる。
【００３６】
図４は、種々の実施形態による、高レベル概念を示す。システムクロック構成モジュール４１０は、システムクロックｉｃｄ＿ｓｙｓ＿ｃｌｋを生成する。システムクロックは、４相のｔｒｃ＿ｑ＿ｃｌｋｓ信号、すなわち、ｔｒｃ＿ｑ１＿ｃｌｋ、ｔｒｃ＿ｑ２＿ｃｌｋ、ｔｒｃ＿ｑ３＿ｃｌｋ、およびｔｒｃ＿ｑ４＿ｃｌｋを生成する、トレースＱ−ジェネレータ４２０によって使用される。図１１は、システムクロックｃｌｋｉｎおよび命令の実行に関する関連直交信号の例示的タイミング図を示す。本実施形態では、ｃｌｋｉｎから派生した４つのクロックｑ１、ｑ２、ｑ３、ｑ４が、１つの命令を実行するために使用される。トレースクロックは、内部クロックｑ１、ｑ２、ｑ３、ｑ４から派生され得るか、または同じこれらのクロックであり得る。しかしながら、他の実施形態によると、異なる中央処理アーキテクチャが実装され、例えば、単一サイクルにおいて、命令を実行することを可能にし得る。
【００３７】
図５は、トレースＱ−ジェネレータ４２０の図の詳細を示す。これは、例えば、従来の様式において、４つのフリップフロップ５１０、５２０、５３０、および５４０によって形成される４ビット循環シフトレジスタであることができる。リセットソースのいくつかの実施例は、ウォッチドッグタイマＷＤＴリセット、中央処理ユニットによって実行されるＲＥＳＥＴ命令、スタックオーバーフロー／アンダーフローリセット、およびマスタクリアＭＣＬＲリセットである。しかしながら、他のリセットソースおよび信号が、適用され得る。
【００３８】
図４に戻ると、全体的リセットが生じると、リセットアナログユニット４３０は、一般的リセットが、システムクロック構成モジュール４１０を除き、チップ全体にアサートされることを可能にする。これは、システムクロックが、起動し続けることを可能にし、トレースＱ−ジェネレータ４２０、したがって、また、トレースデータジェネレータ１２０も、動作を継続することができる。マイクロコントローラ中央処理ユニット１１０が、リセットに保持されている間、トレースデータジェネレータは、リセット関連トレース情報を記録し、次いで、トレースＱ−ジェネレータに、記録が終了したことを通知する。
【００３９】
全体的リセット条件もまた、例えば、フリップフロップ４５０および４６０によって、それぞれ、ｔｒｃ＿ｑ２＿ｃｌｋ信号およびｔｒｃ＿ｑ４＿ｃｌｋ信号を使用して同期され、トレースＱ−ジェネレータ４２０が停止すると、リセットアナログユニット４３０は、例えば、フリップフロップ４８０によって通知され、システムクロック構成モジュール４３０がリセットすることを可能にする。
【００４０】
リセットアナログユニット４３０の例示的実施形態は、図６に示される。リセットアナログユニット４３０は、システムクロック構成モジュール４１０が、そうするように通知された後、リセットすることを可能にする。システムクロック構成モジュール４３０がリセットすると同時に、ワンショットパルスｔｒｃ＿ｒｅｓｅｔ＿ｏｓ１＿ｐｕｌｓｅが、生成され、回路全体が、別のリセット発生検出のために再度備えていることができるように、シンクロナイザレジスタ要素４５０、４６０、４８０をリセットする。図６に示されるように、論理は、種々の制御信号を生成するために提供されることができる。他の論理回路も、デバイスの一般的設計に応じて、使用および適合されることができる。
【００４１】
このような種々の実施形態は、したがって、レベル高感度リセットおよびエッジ高感度リセットの両方に対処する能力を有し、リセットが生じるとすぐにマイクロコントローラシステム全体（システムクロック構成モジュールを除く）が、リセットすることを可能にし、したがって、命令トレースが進行中であってもネイティブ動作により近い。
【００４２】
種々の実施形態は、モジュールが、チップリセットが生じるとすぐにリセットすることを防止された場合でも、システムクロック構成モジュールをリセットするために、最小パルス幅持続時間が保証されることを確実にする。
【００４３】
以下のセクションは、デバイスと外部デバッグツールとの間のトレースデータインターフェースについて詳述する。例えば、図７に示されるようなトレースサブシステムは、デバッグツールによって捕捉および分析され得る、命令実行ストリームのリアルタイム記録を提供する。トレース動作は、デバッグツールが、ソースコードおよびプログラムメモリコンテンツへのアクセスを有し、ＣＰＵ動作のいくつかの側面を推測することができると仮定する。
【００４４】
命令が、ＰＣＬに書き込むと（直接またはＩＮＤｘを通してのいずれか）、新しいＰＣは、プログラムメモリ内の任意の場所にあり得る。この場合、命令パケットは、いわゆるフルプログラムカウンタ（ＦＰＣ）パケットによって取って代わられる。ＦＩＦＯは、図７に示されるように、コアデータレートをデバッグツールデータレート（ＴＲＳＴＡＬＬによって統制される）と一致させるために使用されることができる。ＦＩＦＯは、図７に図示されるように、ＣＰＵエンコーダから充填され、データエンコーダによって排出される。ＦＩＦＯは、最大４０９６命令パケットを保持するが、有効動作サイズは、それぞれの制御ビットによって選択され得る。ＷＡＴＣＨイベントパケットもまた、ＦＩＦＯ内に置かれ、したがって、処理中（ｉｎ−ｆｌｉｇｈｔ）の命令パケットの実際の数は、通常、それより少ないであろう。ＴＲＣＬＫ出力は、トグルすると、各クロックエッジに伴って、１データワードを出力する。出力クロックレートは、常時、ＣＰＵ命令レートにリンクされ、ソフトウェアがＳＹＳＣＬＫを変更する場合、またはリセットがＳＹＳＣＬＫを変更する場合、変化するであろう。それぞれの構成によると、出力レートは、常時、命令期間あたり２つのトレースワードであることができる。レートは、命令あたり１および１／２まで減少されることができるが、これは、ＦＩＦＯオーバーフローにつながる可能性が高くなるであろう。ＴＲＣＬＫ出力は、データ変化に伴って、位相が一致するか、またはＴＲＣＰＳビットの設定に応じて、位相がずれるかのいずれかとなるように選択されることができる。ＦＩＦＯ内エンコーディングは、ラインエンコーディングとは異なり、したがって、各ＦＩＦＯ場所は、ＴＲＤＡＴインターフェースにおいて３データワードも表し得る。
【００４５】
トレース機能停止機能が、実装されることができ、構成ビットが、ＴＲＳＴＡＬＬ入力が有効であるかどうか決定し得る。例えば、制御ビットＴＲＸＳＥ＝１および信号ＴＲＳＴＡＬＬ＝１であるとき、トレースＦＩＦＯは、ペイロード境界における排出を停止し、クロックを停止するであろう。ＴＲＳＴＡＬＬ（ｔｒ＿ｓｔａｌｌ＿ｐｉｎ）が‘０’に戻ると、クロッキングは、再開し、ＦＩＦＯは、データを再び排出し始めるであろう。トレースがイネーブルにされ、ＦＩＦＯが空であるとき、ＩＤＬＥまたはＳＬＥＥＰパケットが、デバイスのスリープ状態に従って送信される。ＦＩＦＯはまた、いくつかの実施形態によると、空にされることができ、トレースが、非アクティブ化されることができる。ＦＩＦＯが満杯になる場合、システム応答は、それぞれの制御設定に依存し得る。いずれの場合も、オーバーフロー状態（機能停止される、またはデータをポストしない）は、それぞれの制御レジスタによって選択されるように、ＦＩＦＯが２５％または７５％満杯のいずれかになるまで、持続するであろう。トレース実装に関する他の機能が、いくつかの実施形態によると、追加され得、説明されるようないくつかの機能は、実装されなくいこともある。典型的トレース信号タイミング図は、図８に示される。
【００４６】
トレースペイロードパケットは、ＣＰＵコアが実行する命令および選択されたデータイベントをエンコードし、また、トレースストリーム同期を提供する。ある実施形態によると、ほとんどのパケットは、１つまたは２つの７ビットワード、あるいはＦＰＣパケットの場合、３ワードから成り得る。概して、パケットは、「ワード１」および随意の「ワード２」から成る。しかしながら、他の形式も、異なる実施形態に従って使用され得る。特定の実施形態によると、「ワード１」の値は、パケットを識別し、「ワード２」が存在するかどうかを暗示する。命令実行と同期するパケット（ＥＸ、ＥＸＤ、およびＲＥＳＥＴ等）、およびＷＡＴＣＨ、ＲＥＳＥＴ、およびＴＲＩＧＧＥＲを含む非同期「イベント」パケットは、以下により詳細に説明される。
【００４７】
同期パケットは、実行の順序で送られる。イベントパケットは、イベントとほぼ同時にストリーム中に現れるが、いくつかのイベントが同時に生じる場合、いくつかのレポートは、遅延されるであろう。ある場合には、ＦＰＣは、同期レポートであるが、他の場合には、イベントである。トランスポート層（ＴＲ）パケットＲＥＳＹＮＣ、ＩＤＬＥ、およびＥＮＤは、インターフェースデータストリームの種々の状態を管理および識別するために、要求に応じて挿入される。ＴＲパケットＲＥＳＹＮＣおよびＩＤＬＥは、命令トレースを分析すると破棄され得る。
【００４８】
ＲＥＳＹＮＣパケットは、受信機が、正しく同期されていることを検証し得るように、それぞれの制御ビットによって規定されるように、周期的に挿入される。所定の時間間隔にほぼ対応する時に、他のＦＰＣがその間隔内で送信されなかった場合のみ、ＦＰＣは、ストリームに追加されるであろう。これは、受信機が命令ストリームを正しく追跡していることのチェックを提供する。挿入されたＦＰＣは、常時、追従する命令のアドレスを示す。パケット内のワード数は、パケットワード１の値によって決定される。ＲＥＳＹＮＣが、「ワード２」に対する正しくない値を伴うワード１として受信される場合、ストリームは、同期からずれ、エラーがフラグされるはずである。
【００４９】
表１は、２ワードパケットを伴う、最悪の場合の状況を図示し、２番目のワードは、０ｘ７Ｄであり、その後に、ＲＥＳＹＮＣが続く。受信機が適切に同期されている場合、受信されたワード＃３は、ワード１となり、ワード＃４は、ワード２となり、パケット＃２として示される完全なＲＥＳＹＮＣ対を形成するであろう。パケット＃３は、ワード＃５から開始し、正しく解釈されるであろう。
【００５０】
【表１】
2015516637.tif 000003
【００５１】
表２は、第１のワードを複製し、受信機を同期から外す、クロックバウンスを伴う同一のデータを示す。ワード＃１および＃２は、データ＝０ｘ７１（但し、これは、正しくない解釈である）を伴うＥＸＤパケットとして受信され、ワード＃３および＃４は、ＲＥＳＹＮＣ対として現れる。ワード＃５は、新しいＲＥＳＹＮＣパケットのワード１として見なされるが、ワード＃６は、０ｘ７Ｄではなく、同期から外れた状態を表す。ワード＃６は、新しいパケットを開始する。
【００５２】
【表２】
2015516637.tif 000004
【００５３】
トレースが開始する場合、またはデバッグ実行のために一時中断された後にトレースが再開する場合に送信される第１のパケットは、常時、ＦＰＣであろう。フルプログラムカウンタ（ＦＰＣ）パケットは、ストリーム内に現れる次の命令の絶対アドレスをレポートする。ＦＰＣは、以下の状況においてレポートする。
−トレースの開始、
−オーバーフロー後の再開、および
−デバッグ後の再開、単に、次の命令のアドレスを示す。
【００５４】
ＦＰＣの全ての他の使用は、命令が実行され、ある場合には、その命令に対してレポートされたであろうパケットを置換することを示す。ＦＰＣが、分岐またはプログラムカウンタ変更命令の実行を表す場合、レポートされる値は、分岐標的アドレスである。ＦＰＣに続く命令パケットは、ＦＰＣが指し示す命令の実行を表す。
【００５５】
ＧＯＴＯおよびＣＡＬＬ命令は、プログラムカウンタＰＣ［１０：０］の最下位ビットが、デバッグ環境（アセンブリコード内）に対して既知であり、新しいＰＣの上位４ビットのみ、上位部分プログラムカウンタ（ＵＰＣ）パケットにおいてレポートされると仮定する。しかしながら、他の実施形態は、より多いまたはより少ない情報をレポートし得る。レポートされる値は、０ｘ０Ｆ＆（ＰＣＬＡＴＨ＞＞３）であることができ、ＰＣＬＡＴＨは、プログラムカウンタの上位ビットにラッチする、実装固有のレジスタを表す。相対分岐（ＢＲＡ）の宛先は、ソースコードに既知であるので、命令は、単に、ＥＸとしてレポートされる。種々のトレースペイロードが、実装され得る。表３は、異なるペイロード信号の例を示す。
【００５６】
【表３】
2015516637.tif 000005
【００５７】
表４は、実際のトレース実施例を示す。
【００５８】
【表４】
2015516637.tif 000006
【００５９】
トリガ入力の変化は、それぞれの制御ビットが設定されている場合、トレースパケットを生成するであろう。極性ビット＝０である場合、イベントは、立ち上がりエッジでトリガするであろう。極性ビット＝１である場合、イベントは、立ち下がりエッジでトリガするであろう。命令が、直接または間接的のいずれかにおいて、プログラムカウンタＰＣＬに書き込むと、新しいＰＣは、プログラムメモリ内の任意の場所にあり得る。この場合、命令パケットは、ＦＰＣパケットによって置換される。
【００６０】
ＦＩＦＯは、コアデータレートをデバッグツールデータレート（ＴＲＳＴＡＬＬによって統制される）と一致させるために使用される。ＦＩＦＯは、図６によって図示されるように、ＣＰＵエンコーダから充填され、データエンコーダによって排出される。ＦＩＦＯは、最大４０９６命令パケットを保持するが、有効動作サイズは、制御レジスタ内のそれぞれのビットによって選択される。ＷＡＴＣＨイベントパケットもまた、ＦＩＦＯ内に置かれ、したがって、処理中の実際の命令パケットの数は、通常、より少ないであろう。
【００６１】
ＴＲＣＬＫ出力は、トグルすると、各クロックエッジに伴って、１データワードを出力する。出力クロックレートは、常時、ＣＰＵ命令レートにリンクされ、ソフトウェアがＳＹＳＣＬＫを変更する場合、またはリセットがＳＹＳＣＬＫを変更する場合、変化するであろう。関連付けられた制御レジスタ内のそれぞれのビットフィールドが設定されると、出力レートは、常時、命令期間あたり２トレースワードとなり得る。レートは、いくつかの実施形態によると、命令あたり１および１／２まで減少されることができるが、これは、ＦＩＦＯオーバーフローにつながる可能性が高くなるであろう。トレースクロックＴＲＣＬＫ出力は、データ変化に伴って、位相が一致するか、またはＴＲＣＰＳ制御ビットの設定に応じて、位相がずれるかのいずれかとなるように選択されることができる。ＦＩＦＯ内エンコーディングは、ラインエンコーディングとは異なり、したがって、各ＦＩＦＯ場所は、ＴＲＤＡＴインターフェースにおいて３データワードも表し得る。
【００６２】
図９は、トレースサブシステム７００の簡略化されたブロック図を示す。サブシステム７００は、命令コードをコアおよびＷＡＴＣＨイベント信号から受信し、ＴＲＤＡＴ信号上における配信のために、このデータをフォーマットする。シーケンスコントローラ７１０は、命令およびＷＡＴＣＨデータをＦＩＦＯにロードすることに関与する。各データパケットは、単一１６−ビットワードとしてエンコードされる。ｑ３４の間、ＷＡＴＣＨ信号は、サンプリングされ、最高優先順位の信号が、エンコード、ロード、およびリセットされる。２つ以上の信号が、アサートされる場合、最高優先順位の信号のみ、ロードされ、他は、後続ｑ３４の機会を待たなければならない。レポート優先順位は、ブレークポイント番号に基づくので、イベントは、順序外でレポートされ得る。ｑ１２の間、以前の命令からのデータは、エンコードおよびロードされる（オプコードは、ｑ３においてエンコードされ、バスデータは、安定しｑ３−ｑ３、全て、立ち上がりｑ１において有効である）。概して、これは、命令期間毎に生じる。分岐および呼び出し命令ならびにインタラプトサイクルの場合、第１のサイクルの間、何もロードされず、パケットは、２回目のサイクルの間、エンコードされ（いわゆる「強制ＮＯＰ」）、ＵＰＣおよびＦＰＣが、正しいＰＣ値とともに送られることを可能にする。その結果、２つのＷＡＴＣＨパケットが、分岐の間、ロードされ得る。ＳＫＩＰおよびＳＴＡＬＬは、現在のコア動作に基づいてエンコードされる。
【００６３】
シーケンスコントローラ７１０は、命令サイクルあたり２回ロードすることができ、ストリームマネージャ７３０は、命令サイクルあたり２回アンロードすることができ、命令サイクルあたり最大４メモリサイクルを要求する。ＦＩＦＯコントローラ７２０は、シーケンスコントローラ７１０によって提供されるデータを管理する。データは、ストリームマネージャ７３０によって要求されると、同一の順序で配信される。ストリームマネージャ７３０は、１６−ビットＦＩＦＯワードをＴＲＤＡＴ信号で伝送されるデータワードに再フォーマットする。いくつかのパケット（例えば、ＥＸ）は、ＦＩＦＯワード毎に単一ＴＲＤＡＴワードをもたらす一方、他（例えば、ＦＰＣ）は、より多くをもたらす。要求に応じて、トランスポート管理パケットＲＥＳＹＮＣ、ＩＤＬＥ、およびＥＮＤが、ストリーム内に挿入され、読み出し動作は、ＴＲＳＴＡＬＬ入力に従って中断される。２つのＴＲＤＡＴワードが、各命令サイクル期間の間に伝送される。ＴＲＣＬＫ信号は、システムリセットの間、中断する（サイクルの一部を引き伸ばす）であろう（データは、損失されないであろう）。
【００６４】
図１０は、トレース受信機として動作するデバッグツール８２０と連結される、種々の実施形態による、マイクロコントローラ８１０を伴うシステム８００を示す。デバッグツールは、例えば、出願人によって製造された回路エミュレータ内のＲｅａｌ−ＩＣＥであることができる。受信機８２０は、トレース同期を行い、全ＩＤＬＥおよびトランスポートパケットを破棄し、残りのパケットのバンドルを遠隔ホスト８３０、例えば、パケットストリーム解釈が行われる、パーソナルコンピュータまたはワークステーションに伝送する。
・ワード１分析−パケットを３ワード幅データバスに変換する。
・ダブレット（ＲＥＳＹＮＣ、ＯＶＥＲＦＬＯＷ等）を検証し、（ａ）ダブレットが連続ワード中にないとき、または（ｂ）非実装ワード１コード値が認められるとき、同期エラーをフラグする。
・ＩＤＬＥおよび他のトランスポートパケットを破棄し、残りの値をＦＩＦＯにスタックする。
・パケット全体を遠隔ホストに伝送する。
【００６５】
ＴＲＳＴＡＬＬをアサートすると、受信機８２０は、最大もう６つのＴＲＤＡＴワード（２つの連続ＦＰＣパケットの均等物）に加え、再同期パイプラインの待ち行列に追加され得る２ワードを受け取る準備ができる。ＴＲＳＴＡＬＬを解除すると、パケットワード１アラインメント（ａｌｉｇｎｍｅｎｔ）が、保証される。ＩＤＬＥパケットのストリングから、大部分、または時として、全部が、破棄され、遠隔ホストに送られず、帯域幅を削減することができる。非実装オプコードおよびＦＰＣワード３（７’ｈ５ｘ）もまた、同期エラーとしてフラグされ、１ワードパケットとして取り扱われるべきである。
【００６６】
ＦＰＣの３番目のワードは、単一ワードパケットのスタイルでエンコードされる（例えば、コード７’ｈ５ｘ）。同期しているかどうかにかかわらず、例えば、７’ｈ５ｘの任意のワードに続くワードは、新しいパケットのワード１であると仮定され得る。ワード１を追跡する目的のために、ＯＶＥＲＦＬＯＷ、ＲＥＳＹＮＣ、ＳＬＥＥＰ、およびＥＮＤパケットは、１ワードパケットとして取り扱われるべきである。７’ｈ７Ｄが、１ワードパケットとして取り扱われるとき、別の７’ｈ７Ｄ（対にされたＲＥＳＹＮＣワード）である場合でも、続くパケットは、常時、ワード１値となるであろう。ワード１がアラインされた（ａｌｉｇｎｅｄ）（疑似）データは、ダブレット分析に通され、２つのＲＥＳＹＮＣがストリーム内で連続的に現れないとき、同期失敗が認識される。同様に、ＯＶＥＲＦＬＯＷ（７’ｈ７７）は、受信機が同期から外れているときに現れ得、２番目のワードが一致しない場合でも、正確に解釈されなければならない。これもまた、同期エラーをフラグし得る。受信機が、同期から外れている場合、１つのみの７’ｈ７Ｃまたは７’ｈ７Ｆが、最後に現れ得、第２の値を待つ間、ハングアップすることは受信機にとって好適ではないであろうため、同様の論法は、ＳＬＥＥＰおよびＥＮＤパケットにも適用されることができる。その一方で、３つの同じワードが、現れる場合もあり、これも受信機を混乱させるべきではない。
【００６７】
完全分析のために、ホスト８３０は、トレースデータを、マイクロプロセッサをプログラムするために使用されたオリジナルソースコードと比較しなければならない。大部分の命令に対して、トレースデータは、実行が生じたことを示すが、動作詳細は、含まれない。分岐が、ＥＸパケット（ＴＲＦＰＣＢ＝０）のみをもたらすとき、分岐先は、ソースコードを検証することによってのみ決定されることができる。同様に、特定の実施形態によると、ＰＣＬＡＴＨへの書き込みは、部分的データのみを送り、評価を完了するために、ソース知識を要求する。動作に応じて、ＳＴＡＬＬパケットは、影響を受ける命令に先行するか、または続き得る。ＳＴＡＬＬパケットは、ユーザのディスプレイ上にハイライトされた表記によって、非典型的動作（例えば、不揮発性メモリへのファイル選択レジスタ（ＦＳＲ）書き込み）が生じたことの示唆として見られ得る。ＷＡＴＣＨレポートは、多くのパケットによって、トリガ命令を遅延させ得る。高密度に取り込まれたウォッチは、同一のウォッチが、読み出しが生じる前にトリガする場合、実際には損失され得る。ウォッチポイントは、データアドレスのみを識別するので、トレース分析は、直接アドレスモード（ＢＳＲおよびオプコードの知識を要求する）から、または間接モード（ＦＳＲの知識を要求する）からかにかかわらず、データアクセスポインタ値を再構成することができなければならない。ウォッチデータは、常時、ウォッチイベントの最新の発生に由来する。いくつかのＦＰＣパケットは、命令が実行された（例えば、ＲＥＴＵＲＮ命令）ことを暗示するが、他のインスタンスは、単なる参考情報であることに留意されたい。
【００６８】
図１２は、開発プログラムを起動し、例えば、ＵＳＢインターフェースを介して、外部デバッガ／プログラミングユニット５２０と接続される、パーソナルコンピュータ等のホストを伴う、典型的デバッグ／プログラミングシステム５００を示す。外部デバッガプログラミングユニット５２０は、デバッガ／プログラマ５２０内で生成された電源電圧を供給し得る専用インターフェースを提供する。しかしながら、他の実施形態は、専用電源を介して供給電圧を供給し得、標的システムは、自己給電され得る。実際のデバッグ／プログラミングインターフェースは、デバッガ／プログラミングユニット５２０によって提供される単方向性クロック信号ＩＣＤＣＬＫおよび双方向性データラインＩＣＤＤａｔａを伴う、同期シリアルインターフェースによって提供され得る。したがって、最低限でも、３つの接続ライン、ＩＣＤＣＬＫ、ＩＣＤＤａｔａ、および基準電位（ＧＮＤ）が、デバッガ／プログラミングユニット５２０と、最低限として、前述のように、種々の実施形態による、デバッグ／プログラミングインターフェースを伴うマイクロコントローラであり得る、標的システム５１０を連結するために使用され得る。
【００６９】
そのようなシステムは、ユーザが、ホスト上で起動するデバッグプログラムを、プログラムがリアルタイムで実行している間、前述されたような条件を有する種々のブレークポイントを設定し、随意に、追加の接続ラインを通して、トレース情報を受信するようにプログラムすることを可能にする。デバッグソフトウェアは、ソースコード内のその位置に関して、種々のブレークポイントを追跡する間、デバッガ／プログラマ５２０は、それぞれのブレークポイントを設定し、その関連付けられたレジスタを構成する標的デバイスに、ブレークポイント情報を通信する。また、トレース能力の設定および構成は、デバッガ／プログラマ５２０によって、標的デバイス５１０に通信される。例えば、メモリ内に記憶されたデータ値の一致によってトリガされる特定のブレークポイントが、設定され得る。ユーザは、次いで、ホストＰＣ５３０上で起動するデバッガソフトウェアを通して、標的デバイス５１０のソフトウェアの実行を開始する。標的ソフトウェアの実行は、ブレークポイントが検出されるときのみ停止される。しかしながら、トレース情報は、標的プログラムの実行の間、継続して自動転送され得る。ホストコンピュータ５３０は、このトレースデータを評価し、テキスト形態において、またはグラフィカルディスプレイを使用してのいずれかにおいて、それを利用可能にする。前述のように、リセットイベントはまた、種々の実施形態によると、トレースサブシステムが、依然として、クロックされているため、完全にトレースされることができる。
【００７０】
本実施形態は、前述のような特徴を実装することによって、トレースストリームのより優れた分析を可能にする。種々の実施形態は、したがって、オンチップデバッグ能力水準を高め、高度デバッグ能力を多くの異なるユーザにもたらすことを可能にするであろう。
【図１】
2015516637.tif 000007
【図２】
2015516637.tif 000008
【図３】
2015516637.tif 000009
【図４】
2015516637.tif 000010
【図５】
2015516637.tif 000011
【図６】
2015516637.tif 000012
【図７】
2015516637.tif 000013
【図８】
2015516637.tif 000014
【図９】
2015516637.tif 000015
【図１０】
2015516637.tif 000016
【図１１】
2015516637.tif 000017
【図１２】
2015516637.tif 000018
【国際調査報告】
2015516637.tif 000019
2015516637.tif 000020