アプリケーション・ノート 31 EmbeddedICEの使い方 文書番号: ARM DAI 0031CJ-00 発行: 1999年9月 Copyright ARM Limited 1999 Copyright © 1999 ARM Limited. All rights reversed アプリケーション・ノート31 EmbeddedICEの使い方 Copyright © 1999 ARM Limited. All rights reserved. リリース情報 本アプリケーション・ノートには、以下の変更が加えられています。 変更履歴 日付 発行 変更 1999年2月 C リリース3 日本語版 発行 CJ-00 日付 1999年9月 改訂 初版 著作権について ARM、ARM Poweredのロゴ、Thumb、およびStrongARMは、ARM Limitedの登録商標です。 ARM logo、AMBA、Angel、ARMulator、EmbeddedICE、ModelGen、Multi-ICE、ARM7TDMI、ARM9TDMI、TDMI、 およびSTRONGは、ARM Limitedの商標です。 本アプリケーション・ノートに記載されているその他の製品名やサービス名は、それぞれの会社の知的財産で す。 本書は製品を使用する際の補助的なものとして書かれたものです。本製品をご使用になる場合は、英語版をご 利用ください。 キー 文書番号 本書には識別するための番号が固有に付いています。この番号は、表紙及び各ページ下部に記載されています。 ARM XXX 0000 XJ - 00 日本語版の改訂番号 A-Zまでの発行コード 4桁の固有番号 文書の種類 ii Copyright © 1999 ARM Limited. All rights reversed アプリケーション・ノート 31 ARM DAI 0031CJ-00 文書ステータス 文書ステータスは各ページ下部の見出しに記載されています。 これによって、文書の機密性及び記載されている情報の状況を知ることができます。 以下は機密性の状況を示します。 ARM Confidential ARM社員及びNDA署名者のみ閲覧可。 Named Partner Confidential 上記及び指定提携企業の社員のみ閲覧可。 Partner Confidential ARM社員及び全提携企業の社員のみ閲覧可。 Open Access 制約無し。 以下は情報の状況を示します。 Advance 将来の製品に関する情報 Preliminary 開発中の製品に関する最新情報 Final 完成品に関する最終情報 文書の配布について 本文書はオープン・アクセスとなっていますので、配布は自由に行ってください。 本アプリケーション・ノートへのご意見･ご質問 本アプリケーション・ノートに対するコメントがございましたら、以下の情報を指定の上、[email protected]まで 電子メールをお寄せください。 • 文書タイトル • 文書番号 • コメントが該当するページ番号 • コメントの内容 情報の追加や改善に関する一般的なご提案も歓迎いたします。 ARM Webアドレス http://www.arm.com/ Copyright © 1999 ARM Limited. All rights reversed iv Copyright © 1999 ARM Limited. All rights reversed アプリケーション・ノート 31 ARM DAI 0031CJ-00 目次 目次 1 2 3 4 5 6 7 8 9 10 11 12 はじめに EmbeddedICE の基礎 EmbeddedICE インタフェースの接続と電源投入 デバッガと EmbeddedICE インタフェースの設定 ウォッチポイントとブレークポイント ベクタ・ブレークポイントと例外 セミホスティング ROM でのアプリケーションのデバッグ EmbeddedICE マクロセルへの直接アクセス タイマ精度 ターゲット・ボードのメモリ・レイアウト システム設計に関する注意事項 アプリケーション・ノート31 ARM DAI 0031CJ-00 Open Access 2 3 6 7 9 11 13 16 19 21 22 23 1 はじめに 1 はじめに EmbeddedICE は、ARM の RISC プロセッサ・ファミリ・アーキテクチャの拡 張機能であり、システムに深く組み込まれているコアをデバッグするための 機能を提供します。EmbeddedICE は、3 つの部分から構成されています。 • • • ARM コアのデバッグ拡張機能セット 基本のデバッグ拡張機能に JTAG TAP コントローラとブレークポイ ント / ウォッチポイント・ロジックを追加する EmbeddedICE マクロ セル EmbeddedICE マクロセルとホスト・コンピュータとの通信を実現す る EmbeddedICE インタフェースや Multi-ICE などのプロトコル・コ ンバータ（Multi-ICE の使い方については「Multi-ICE User Guide [ARM DUI 0048]」を参照してください） 本アプリケーション・ノートは、EmbeddedICE インタフェースを使用したシ ステムのデバッグに関する問題と、このようなシステムを設計する際の注意 事項について解説します。本アプリケーション・ノートの情報の大部分は、 Multi-ICE を使用する場合にも適用されます。 本アプリケーション・ノートでは、ARM ソフトウェア開発ツールキットの バージョン 2.5 を使用しているものと想定しています。古いバージョン（2.11a など）を使用している場合には、添付されているユーザ・ガイドで詳細を確 認してください。 2 アプリケーション・ノート31 ARM DAI 0031CJ-00 Open Access Named Partner Confidential - Preliminary Draft EmbeddedICE の基礎 2 EmbeddedICE の基礎 2.1 ARM コアのデバッグ拡張機能 名前の最後に D が付いている ARM コアには、デバッグ拡張機能が用意され ています。この拡張機能は、コアを取り巻く多くのスキャン・チェインと追 加ピンから構成されており、デバッグ用にコア動作を制御します 以下の 3 本のピンが最も重要です。 BREAKPT このピンは、外部ハードウェアからデバッグの目的でプロ セッサの実行を停止するために使用します。このピンがハイ のときは、現在のメモリ・アクセスにブレークポイント・タ グが付けられます。このメモリ・アクセスが命令フェッチで あれば、命令がパイプラインの実行ステージに達した時点 で、コアはデバッグ・ステートに入ります。データ アクセ スであれば、現在の命令が実行を完了した時点で、コアはデ バッグ・ステートに入ります。EmbeddedICE マクロセルは、 このコアへの入力をアサートすることもできます。 DBGRQ このピンは、現在の命令が実行を完了した直後にコアがデ バッグ・ステートに入るようにするレベル・センシティブな 入力です。外部ハードウェアは、このピンを使用して、ARM を強制的にデバッグ・ステートに入れることができます。 DBGACK このピンは、ARM からの出力であり、コアがデバッグ・ス テートに入っているときにハイになります。他のペリフェラ ルやデバッグ・システムは、このピンを調べることでコアの 現行ステートを調べ、適切に動作することができます。 詳細は、関連する ARM コア・データシートまたはテクニカル・リファレン ス・マニュアルのデバッグ・インタフェースのセクションを参照してくださ い。 2.2 EmbeddedICE マクロセル EmbeddedICE マクロセルは、ARM コアのデバッグをサポートする統合オン チップ・ロジックです。EmbeddedICE マクロセルが用意されている ARM コ アの名前には、最後に I が付いています。 EmbeddedICE マクロセルは、JTAG インタフェースを使用して、ARM のテス ト・アクセス・ポート（TAP）コントローラを通してシリアルにプログラミ ングされます（この機能をターゲットに組み込む際の詳細は、「12 システム 設計に関する注意事項 」を参照してください）。 EmbeddedICE マクロセルは、2 つのリアルタイム・ウォッチポイント・ユ ニット、コントロールおよびステータス・レジスタ、そしてデバッガとの通 信リンクをインプリメントするレジスタ群（「デバッグ通信チャネル」と呼 ばれます）から構成されます。このリンクについての詳細は、アプリケー ション・ノート 38（ 「デバッグ通信チャネル」）を参照してください。片方ま たは両方のウォッチポイント・ユニットは、ARM コアによる命令実行を停 止させるBREAKPT信号を出力するようにプログラミングすることができま す。命令の実行は、EmbeddedICE マクロセルにプログラミングされている値 とアドレス・バス、データ バス、およびさまざまな制御信号の現在値が一致 した時点で停止します。マスクされているビットは、比較の対象から外され ます。どちらのウォッチポイント・ユニットも、ウォッチポイント（データ・ アクセスの監視）またはブレークポイント（命令フェッチの監視）として設 定することができます。 アプリケーション・ノート31 ARM DAI 0031CJ-00 Open Access 3 EmbeddedICE の基礎 詳細は、ARM コア・データシートまたはテクニカル・リファレンス・マニュ アルの関連セクションを参照してください。 2.3 プロトコル・コンバータ プロトコル・コンバータは、デバッガから送信されたデバッグ・プロトコル・ メッセージを、EmbeddedICE マクロセルに送信可能な JTAG 信号に（そして その逆に）変換します。本アプリケーション・ノートの執筆時点では、ARM は EmbeddedICE インタフェースと Multi-ICE ユニットの 2 種類のプロトコ ル・コンバータを提供しています。 EmbeddedICE インタフェース EmbeddedICE インタフェースは、ARM オリジナルのプロトコル・コンバー タです。このインタフェースは、内蔵シリアル・ポートだけ、もしくは内蔵 シリアル・ポートおよびパラレル・ポートの両方を使用して、ホスト・コン ピュータに接続することができます。シリアル・ポートは両方向転送用に使 用できますが、パラレル・ポートを使用する場合には、シリアル・ポートは ダウンロード速度を向上させる（最高で約 15KB/ 秒）目的で使用します。 Multi-ICE ユニット Multi-ICE は、マルチプロセッサ EmbeddedICE インタフェース（Multiprocessor EmbeddedICE Interface）を縮めた名前で、EmbeddedICE インタフェースより 新しく、より多くの種類の ARM コアや、同じ ASIC 内の複数の ARM コアと 通信することができます。Multi-ICE は、パラレル・ポートを使用してホス ト・コンピュータに接続され、ダウンロード速度は、モデム PC では約 100KB/ 秒です（実際の速度はプロセッサやパラレル・ポートによって異なります） 。 2.4 EmbeddedICE とデバッグ・モニタとの違い Angel などのデバッグ・モニタは、ユーザ・アプリケーションと並行してボー ド上で動作し、ボード上で自分用のリソースを必要とします。ボードに電源 を投入すると、Angel はベクタ・テーブルを初期化することによって自身を インストールし、例外の発生時にボードを制御します。ホストから通信が来 ると、割込みが発生し、ユーザ・アプリケーションを停止させて、Angel 内 の適切なコードを呼び出します。その後、Angel はユーザ・アプリケーショ ンに制御を戻します。しかしながら、アプリケーションも割込みにアクセス する必要がある場合には、処理が複雑になります。同様に、アプリケーショ ンがホストに対して何らかのI/Oを要求する場合、この要求はアプリケーショ ン側の SWI 命令でインプリメントされ、SWI 命令は Angel の SWI ハンドラ で処理されます（詳細は「 7 セミホスティング」を参照してください）。こ のため Angel は、ユーザ・アプリケーションの実行中に ARM を制御できる ように、ROM にデバッグ・モニタ・コードを格納し、RAM にデータを格納 して、例外ベクタを制御できる必要があります。 これに対して EmbeddedICE のデバッグ・アーキテクチャは、このようなリ ソースを必要とはしません。ボード上のアプリケーションとして存在するの ではなく、コア上の補助デバッグ・ハードウェアと、コアのデバッグ・ハー ドウェアとホストとの通信を処理するインタフェース・ボックスを組み合わ せて使用します。EmbeddedICE デバッグ・アーキテクチャのデバッグ・アー キテクチャは、できる限り他のアプリケーションを邪魔しないように、JTAG ポートを使用してデバッグを実行します。 4 アプリケーション・ノート31 ARM DAI 0031CJ-00 Open Access Named Partner Confidential - Preliminary Draft EmbeddedICE の基礎 ターゲット・システムは、デバッグをサポートするための特別なハー ドウェアを必要としません（EmbeddedICE マクロセルと JTAG TAP コントローラのみが必要です）。 • ターゲット・システムは、デバッグ用にメモリを確保する必要はな く、デバッグ用に特別なソフトウェアを組み込む必要もありません。 • ターゲット・システムの実行は、ブレークポイントまたはウォッチ ポイントがヒットしたとき、またはデバッグ対象の停止をユーザが 停止したときにのみ停止します。 EmbeddedICE のデバッグ・アーキテクチャでは、ターゲット・システム側 ではデバッグ実行用のメモリは必要ありませんが、ターゲット自身のアプリ ケーション・コードを実行するためのメモリが必要です。 • 注意 2.5 ターゲット上での EmbeddedICE の影響 EmbeddedICE のデバッグは、基本的にはターゲットに影響を与えませんが、 以下の 4 つの例外があります。: • • • • ARM デバッガが起動すると、ターゲット・システムのステートを検 出しようとします。このため、デバッガはターゲットの動作を停止 し、ARM レジスタのステートを調べます。しかしながら、デバッガ の起動後にデバッグ・セッションが開始されると見るのなら、これ はターゲットには影響を与えていないと言えます。 1 ワードを超えるストラクチャやアレイに対するウォッチポイント が存在する場合には、ウォッチポイント領域の付近で書き込みが発 生した時点で、ターゲットは実行を停止します。EmbeddedICE は、 ユーザに対して透過的に実行を再開しますが、アプリケーションが リアルタイムである場合には、問題の原因となることもあります。詳 細は、「4.1 armsd の設定」も参照してください。 セミホスティング : ホスト・コンピュータから I/O 機能を提供する ためのメカニズムです。セミホスティングを使用するためには、プ ロトコル・コンバータがベクタ・テーブルの SWI エントリを制御す る必要があります。詳細は、 「 7.1 EmbeddedICE を使用する際のア プリケーション SWI ハンドラの追加」を参照してください。 ベクタ : 開発の早期などにおいて、アプリケーションがハンドラを 用意していない場合に例外を止めるためのメカニズムです。このメ カニズムを使用するためには、ベクタ・テーブルでブレークポイン トをオンに設定する必要があります。詳細は、 「 6 ベクタ・ブレーク ポイントと例外 」を参照してください。 アプリケーション・ノート31 ARM DAI 0031CJ-00 Open Access 5 EmbeddedICE インタフェースの接続と電源投入 3 EmbeddedICE インタフェースの接続と電源投入 EmbeddedICE インタフェースは、ホスト・コンピュータと ARM ターゲット・ ボードの両方に接続する必要があります。 注意 Multi-ICE の接続と電源投入についての詳細は、「Multi-ICE ユーザ・ガイド [ARM DUI 0048]」を参照してください。 EmbeddedICE インタフェースの接続と電源投入の手順は次の通りです。 1 添付のシリアル・ケーブルを EmbeddedICE インタフェースの 9 ピン・ シリアル・ポートとホスト・コンピュータのシリアル・ポートに接 続します。 2 任意の手順として、 添付の25芯D型パラレル・ケーブルを、 EmbeddedICE のパラレル・ポートとホスト・コンピュータのパラレル・プリンタ・ ポートに接続します。 3 該当文書の指示にしたがってターゲット・ボードに電源を投入しま す。 4 EmbeddedICE インタフェースを外部の DC +7 ∼ +9V （無調整） 、500mA 以上の電源に接続します。推奨電圧は +7.5V です。 2.1mm の電源コネクタの中央ピンに正極が接続されるように注意し てください（ 「 図 3-1: 電源の接続」参照）。 接地 0V +7 ∼ +9V 図 3-1: 電源の接続 6 5 14 芯 IDC JTAG ケーブルを使用して、EmbeddedICE インタフェース をターゲット・ボードに接続します（実際の JTAG 接続位置は、使 用しているターゲット・ボードによって異なります。詳細はボード の添付文書を参照してください）。 6 EmbeddedICE インタフェースに電源を投入します。赤い LED が点灯 します。 7 これで、EmbeddedICE インタフェースを使用してデバッグ・セッショ ンを実行する準備ができました。 アプリケーション・ノート31 ARM DAI 0031CJ-00 Open Access Named Partner Confidential - Preliminary Draft デバッガと EmbeddedICE インタフェースの設定 4 デバッガと EmbeddedICE インタフェースの設定 EmbeddedICE インタフェースがターゲット・ハードウェアにアクセスする方 法とは、内蔵 ROM に格納されているソフトウェア・イメージ（エージェン ト）による制御です。このソフトウェアには、EmbeddedICE インタフェース が 2 種類の ARM コアと対話するために必要な次のコンフィギュレーション・ ファイルが含まれています。 ARM7DI デバッグ拡張機能とEmbeddedICE マクロセルを備え た ARM7 コア（ARM7DMI を含む） ARM7TDI Thumb、デバッグ拡張機能、および EmbeddedICE マ クロセルを備えた ARM7 コア（ARM7DMI を含む） EmbeddedICE インタフェースを起動すると、インストールされているエー ジェントのバージョンにしたがって、特定のコンフィギュレーションを自動 的にデフォルト設定します。通常は ARM7TDI になります。 現在のコンフィギュレーションは、デバッガで簡単に変更できます。詳細は、 「 4.1 armsd の設定 」と「 4.2 ADW/ADU の設定 」も参照してください。 注意 常に正しいコンフィギュレーションを選択してください。コンフィギュレー ションが間違っていると、イメージを実行する際に問題が発生します。 ARM7DI で ARM7TDI コンフィギュレーションを使用すると、ブレークポイ ントがヒットしなくなります。^C キー（armsd を使用している場合）または Stop ボタン（ADW を使用している場合）を押して実行を停止すると、未定 義の命令トラップに入ります。 ARM7TDI で ARM7DI コンフィギュレーションを使用すると、ADW で空白 の実行ウィンドウが表示されます。 次のメッセージが表示された場合には、間違ったコンフィギュレーションが 使用されていて、EmbeddedICE インタフェースがターゲットと同期できない ことを意味します。 Target processor not stopped ただし、別の原因によってこの問題が発生することもあります。「12 システ ム設計に関する注意事項」を参照してください。 デバッガの起動時（またはイメージの再ロード時）に次のメッセージが表示 された場合、通常は無視しても構いません。 Error during initialization: Recoverable error in RDI initialization 現在のバージョンで問題がある場合には、供給先に連絡して、最新バージョ ンのエージェントを入手してください。詳細は、http://www.arm.com の Web サイトを参照してください。本アプリケーション・ノートの執筆時点で は、最新バージョンは 2.07 です（ソフトウェア開発ツールキット 2.11a およ び 2.50 に添付されています）。 注意 初期の EmbeddedICE インタフェースには、バージョン 1.0x のエージェン ト・ソフトウェアが添付されています。これらのバージョンは、リモート・ デバッグ・プロトコル（RDP）を使用してデバッガと通信しており、セミホ スティングで（Angel SWI ではなく）Demon SWI を使用するプログラムと の互換性を持っています。詳細は、 「アプリケーション・ノート 39 Demon および RDP [ARM DAI 0039]」を参照してください。ソフトウェア開発ツー ルキットのバージョン 2.5 では、RDP は使用できません。したがって、バー ジョン 1.0x のエージェントを使用している場合には、ROM をバージョン 2.0x にアップグレードする必要があります。 アプリケーション・ノート31 ARM DAI 0031CJ-00 Open Access 7 デバッガと EmbeddedICE インタフェースの設定 新バージョンのエージェントを置き換えるには 新しいバージョンのエージェントは、次のいずれかの方法で使用できます。 • • 注意 4.1 新バージョンのエージェントで新しい EPROM（AM27C010-120DC もしくは同等品）をプログラミングし、EmbeddedICE インタフェー スの回路ボード（2 枚あるうちの下の方）に取り付けられている現在 の EPROM を新しい EPROM で交換します（回路ボードは正しく取 り付けてください） 。 デバッガの loadagent コマンドを使用して、デバッグ・セッションの 最初に新しいイメージをダウンロードします。詳細は、 「 4.1 armsd の設定 」も参照してください。 EmbeddedICE インタフェースの電源を入れ直したり、Reset ボタン を押したりした場合には、再び新しいイメージをダウンロードしな ければなりません。 EmbeddedICE インタフェースで新しいイメージをダウンロードした場合、 以降にデバッガを起動するたびに、ROM CRC チェックに失敗したことを示 すメッセージが表示されます。これは、ダウンロードしたイメージが ROM 内のイメージに対して CRC チェックを実行し、ROM のチェックサムが異 なっているためです。したがって、このメッセージは無視しても構いません。. armsd の設定 リモート・ターゲットのデバッグを制御する際のオプションについての詳細 は、「ARM ソフトウェア開発ツールキットリファレンス・ガイド [ARM DUI 0041]」のセクション 7.2.1 を参照してください。 たとえば、標準シリアルおよびパラレル・ポートを使用して、EmbeddedICE がサポートする最高回線速度で実行可能サンプル・イメージをリトル・エン ディアン・ターゲットにダウンロードするには、次のように入力します。 armsd -li -adp -port s,p -linespeed 38400 example 引数の意味は次の通りです。 -li は、リトル・エンディアン・スイッチです。ビッグ・エン ディアンの場合は -bi と指定します。. -adp は、Angel デバッグ・プロトコルを使用したリモート・デ バッグを選択するためのスイッチです。 -port s,p は、標準シリアルおよびパラレル・ポートを使用すること を指定します。 -linespeed は、使用するシリアル回線速度を指定します。 example は、ファイル名です。 armsdを起動した後も、EmbeddedICEインタフェースのコンフィギュレーショ ンやエージェント機能を変更するためのコマンドを使用できます。ただし、 ほとんどの場合には、これらのコマンドを使用する必要はありません。詳細 は、「ARM ソフトウェア開発ツールキットリファレンス・ガイド [ARM DUI 0041]」のセクション 7.8 を参照してください。 4.2 ADW/ADU の設定 EmbeddedICE と通信するための ADW/ADU の設定についての詳細は、 「ARM ソフトウェア開発ツールキット・ユーザー・ガイド [ARM DUI 0040] 」のセ クション 3.7.3 および 3.7.4 を参照してください。 8 アプリケーション・ノート31 ARM DAI 0031CJ-00 Open Access Named Partner Confidential - Preliminary Draft ウォッチポイントとブレークポイント 5 ウォッチポイントとブレークポイント ARMulator と同じように、ARM デバッガも EmbeddedICE でリンクされたター ゲットに対するブレーク、ウォッチ、アンブレーク、およびアンウォッチ機 能を備えています。しかしながら、以下の点に注意する必要があります。 5.1 ウォッチポイント すべての ARM デバッガ・ウォッチポイントは、データ変更ウォッチポイン トです。つまり、データ・ポイントがリードまたはライトされても、メモリ に格納されているデータ値と同じであれば、ウォッチポイントはヒットしま せん。 他の形式のウォッチポイントをインプリメントする方法については、 「9 EmbeddedICE マクロセルへの直接アクセス 」も参照してください。 ハードウェア・ウォッチポイントとソフトウェア・ウォッチポイント ハードウェア・ウォッチポイントは、EmbeddedICE マクロセル・ポイントを 使用して、マスク内のアドレスへのデータ・ライトを検出します。このタイ プのウォッチポイントは、関連するデータがライトされた場合にのみコアの 実行を停止させるので、効率的です。しかしながら、このウォッチポイント は完全に EmbeddedICE マクロセル・ポイントに連結されます。また、スト ラクチャまたはアレイに対してウォッチポイントを設定する場合には、 ウォッチポイント対象のオブジェクトの一部ではないアドレスもマスクに 含まれることがあります。この場合、これらの不要なアドレスへのライトは EmbeddedICE インタフェースによってフィルタされます。したがって、不要 なウォッチポイントのヒット時にもプロセッサの実行が停止して、その後に EmbeddedICE インタフェースによって自動的に実行が再開されるため、性能 が若干低下します。 ソフトウェア・ウォッチポイントは、EmbeddedICE マクロセルを使用しませ ん。各命令の実行後に、関連するデータ位置の値が変更されたかどうかが調 べられ、値が変更されていれば実行が停止します。そうでなければ、実行が 再開します。このタイプのウォッチポイントは、実行性能を大幅に低下させ ます。また、メモリのライト・オンリ領域（メモリ・マップド・デバイス・ レジスタなど）にも使用できません。 5.2 検査ポイント 現在のブレークポイントやウォッチポイントを（armsd では break または watch コマンドを使用して、ADW/ADUでは View メニューからBreakpoints または Watchpoints オプションを選択して）検査すると、それらのポイン トがハードウェアまたはソフトウェアのどちらであるかが示されます。 ハードウェア・ブレークポイントとソフトウェア・ブレークポイント ハードウェア・ブレークポイントは、EmbeddedICE マクロセル・ポイントを 使用してインプリメントされ、適切なアドレスからの命令フェッチを検出し ます。このブレークポイントは、デバッグ対象のプログラムが実行中に自身 を変更したり、コードが ROM に格納されていたりする場合を含み、すべて のケースに適用できます。しかしながら、2 つの EmbeddedICE マクロセル・ ポイント・ユニットのいずれかに完全に連結されます。 ソフトウェア・ブレークポイントは、EmbeddedICE マクロセル・ポイントを 使用してインプリメントされ、特定のビット・パターンの命令フェッチを検 出します。このビット・パターンは、適切な位置に格納され、実際の命令は アプリケーション・ノート31 ARM DAI 0031CJ-00 Open Access 9 ウォッチポイントとブレークポイント ホスト・デバッガのメモリに格納されます。したがって、自身を変更する コードや ROM に格納されているコードは、このタイプのブレークポイント ではデバッグできません。 （EmbeddedICE は、書き込み不能なメモリを検出 し、その領域に対してはソフトウェア・ブレークポイントを使用します。）1 つの EmbeddedICE マクロセル・ポイントでは、任意数のソフトウェア・ブ レークポイントをサポートできます。 5.3 ウォッチポイント、ブレークポイント、およびプログラム・カウンタ ウォッチポイントは、対象となるデータが変更された時点で成立します。こ のときに、ウォッチポイントを成立させた命令の直後の命令を指すように、 プログラム・カウンタが更新されます。したがって、ウォッチポイント対象 データは、古い値ではなく、新しい値になります。 ブレークポイントは、ブレークポイント対象の命令がパイプラインの実行ス テージに達した時点（ただし命令が実行される前）で成立します。したがっ て、ブレークポイントが成立した時点では、プログラム・カウンタは更新さ れず、ブレークポイントを成立させた命令のアドレスを保持します。 注意 10 ARM コアの内部では、プログラム・カウンタは、現在実行中の命令の 2 つ 後の命令（パイプラインのフェッチ・ステージにロードされている命令のア ドレス）を指します。したがって、ARM デバッガは、デバッガ内部で表示 されたときにはプログラム・カウンタの内容が実行中（または実行直前）の 命令のアドレスになっているように、プログラム・カウンタの修正後の値を レポートすることによって、この処理を簡素化します。 アプリケーション・ノート31 ARM DAI 0031CJ-00 Open Access Named Partner Confidential - Preliminary Draft ベクタ・ブレークポイントと例外 6 ベクタ・ブレークポイントと例外 デ バ ッ ガ が タ ー ゲ ッ ト・ア プ リ ケ ー シ ョ ン の 実 行 を 開 始 す る と、 EmbeddedICE インタフェースは、デバッガの内部変数 $vector_catch で 指定されているブレークポイントを有効にします（つまり、実行を開始した 時点で、ユーザ指定のブレークポイントとウォッチポイントを、ハードウェ アからソフトウェアへ警告なしで格下げしなければならないことがありま す）。$vector_catch 変数は、いろいろな条件が発生した場合に実行をト ラ ッ プ す べ き か ど う か を 指 定 す る た め に 使 用 し ま す。デ フ ォ ル ト 値 は %RUsPDAifE で、大文字がトラップ条件を示しています。 ブレーク ポイント 説明 R リセット U 未定義命令 S SWI P プリフェッチのアボート D データのアボート A アドレス例外 I IRQ F FIQ E エラー（将来インプリメントされる可能性のあるソフトウェア による障害検出機能用に予約） 表 6-1: ブレークポイント 特 定 の 例 外 に 対 し て 特 別 な ハ ン ド ラ を 用 意 し て い な い 場 合 に は、 $vector_catch 変数を使用すると便利です。 OARM9TDMI ファミリ・デバイスでは、コアの補助ハードウェアによって、 ブレークポイントを設定しなくてもベクタを捕捉することができます。詳細 は、 「ARM9TDMI テクニカル・リファレンス・マニュアル」を参照してくだ さい。 通常は、$vector_catch 変数の SWI フラグは小文字のままにしておきま す。これは、デバッガ内部変数の $semihosting_enabled お よ び $semihosting_vector によってより詳細な制御が行われるためです（詳 細は「 7 セミホスティング 」を参照してください）。$vector_catch 変数 の s ビットをセットすると、予測できない結果となります。 アクティブな割込みソースを持つ割込みハンドラが 1 つもないシステムで は、下記の命令をロードして、すべての割込みをマスクするように例外ベク タを設定してください。 アプリケーション・ノート31 ARM DAI 0031CJ-00 Open Access 11 ベクタ・ブレークポイントと例外 この設定を行うには、armsd のプロンプトに対して以下のコマンドを実行し ます。セミコロン（;）の後のテキストは、16 進値でエンコードされている コマンドについてのコメントですから、入力する必要はありません。 0x18 = 0xe1a00000; NOP 0x1C = 0xe14fd000; MRS r13, spsr 0x20 = 0xe38dd0c0; ORR r13, r13, 0xC0 0x24 = 0xe169f00d; MSR spsr, r13 0x28 = 0xe25ef004; SUBS pc, lr, #4 上記のコマンドを armsd.ini 起動ファイルに指定しておくと便利です。こ の場合には、armsd の起動時にコマンドが実行されます。armsd 起動ファイ ルの作成については、 「ARM ソフトウェア開発ツールキット・リファレンス・ ガイド [ARM DUI 0041]」を参照してください。 ADW または ADU を使用している場合には、View メニューから Memory を 選択し、適切なアドレスの内容を修正してください。もしくは、コマンド・ ウィンドウからスクリプトを呼び出します。 リアルタイムで発生する割込みに依存するアプリケーションでは、若干の問 題が考えられます。EmbeddedICE で go 以外の何らかの操作（たとえば、ブ レークポイントのヒット）を行うと、デバッグ・ステートへの移行に時間が 掛かるため、動作中に割込みが発生することがあります。この問題が大きい 場合には、割込みを（起動ファイルを修正するか、もしくは CPSR をマニュ アルで設定することで）オフにします。割込みが必要な場合には、デバッガ を使用して正しいモードに入り、pc をベクタ・アドレスに設定して、実行 を再開してください。 6.1 ROM が 0x0 にある場合の $vector_catch 変数 ROM がアドレス 0x0 にあるシステムでは、$vector_catch 変数の設定に 注意が必要です。詳細は、「 8 ROM でのアプリケーションのデバッグ 」を 参照してください。 12 アプリケーション・ノート31 ARM DAI 0031CJ-00 Open Access Named Partner Confidential - Preliminary Draft セミホスティング 7 セミホスティング セミホスティングとは、デバッガが動作しているホスト・コンピュータに対 して ARM ターゲットがアプリケーション・コード中の I/O 要求を送るメカ ニズムで、標準 ANSI C ライブラリの printf() や scanf() と似ています。 セミホスティングにより、ターゲット・システム自身が画面、キーボード、 およびディスクを持つ必要がなくなります。 Angel が動作しているターゲット・ボードでは、定義済みの SWI 群によって セミホスティングをインプリメントします。したがって、Angel はボードの 電源投入時に SWI ハンドラをインストールし、ターゲットが SWI 命令を実 行すると、Angel はホストとの間で必要な通信を実行します。 EmbeddedICE インタフェースを使用している場合には、セミホスティングの 処理方法は少し変わります。この場合のセミホスティングは、Angel が SWI ベクタ上にインストールするSWIハンドラをエミュレートすることによって インプリメントされます。EmbeddedICE インタフェースは、SWI ベクタ上に ブレークポイントをインストールし、このブレークポイントがヒットする と、その SWI 番号をチェックします。SWI がセミホスティング SWI として 認識されれば、EmbeddedICE インタフェースはその SWI をエミュレートし て、アプリケーションの実行を透過的に再開します。SWI がセミホスティン グ SWI として認識されない場合には、EmbeddedICE インタフェースはプロ セッサを停止してエラーを報告します。 このセミホスティング・メカニズムは、以下のデバッガ内部変数を使用して 無効にしたり、動作を変更したりできます。 $semihosting_enabled この変数のデフォルト値は 1 で、セミホスティングは有効に 設定されています。この変数を 0 に設定すると、セミホス ティングは無効になります。たとえば、ROM から実行され るアプリケーションをデバッグする場合には、この変数が便 利です。このような場合にセミホスティングを無効に設定す る と、ウ ォ ッ チ ポ イ ン ト・ユ ニ ッ ト が 解 放 さ れ ま す。 $semihosting_enabled 変数のかわりに $vector_catch 変数の s ビットをセットしてはいけません。 $semihosting_vector この変数は、EmbeddedICE インタフェースがセミホスティン グ SWI を検出するために設定したブレークポイントの位置 を制御します。デフォルト値は 8 です。EmbeddedICE インタ フェースは、セミホスティング SWI の処理後には、コード 中の SWI 命令の直後の命令に直接戻り、$semihosting_ vector アドレスの内容を完全にバイパスします（これは、 lr の内容を調べることによって行われます）。 この変数が 0 に設定されていても、アドレス 0 という意味 ではなく、アドレス 8 が使用されますので注意してくださ い。しかしながら、$vector_catch 変数の値には関係な く、すべての例外と割込みがトラップされ、エラー条件と してレポートされます。 ADW/ADU では、View メニューから Debugger Internals を選択するか、コ マンド・ライン・ウィンドウを使用して、これらの変数にアクセスすること ができます。 アプリケーション・ノート31 ARM DAI 0031CJ-00 Open Access 13 セミホスティング 注意 7.1 Multi-ICE を使用している場合には、別の方法でセミホスティングをインプリ メントすることもできます。この方法では、セミホスティングが有効である 間もコアが停止しないように、デバッグ通信チャネルを使用します。この方 法を使用するには、$semihosting_enabled 変数を 2 に設定します。詳細 は、「Multi-ICE User Guide [ARM DUI 0048]」を参照してください。 EmbeddedICE を使用する際のアプリケーションSWI ハンドラの追加 多くのアプリケーションでは、セミホスティング SWI を使用するだけではな く、ベクタ・テーブルに独自の SWI ハンドラをインストールする必要もあり ます。この場合には、アプリケーションの SWI ハンドラが EmbeddedICE の セミホスティング・メカニズムと正常に共同作業できるような方法でインス トールしなければなりません。そのためには、アプリケーションの SWI ハン ドラをベクタ・テーブルにインストールします。次に、アプリケーションの SWI ハンドラが SWI を認識しない（もしくはセミホスティング SWI として 認識する）場合にのみ到達するアプリケーション・ハンドラの終端位置を指 すように、$semihosting_vector 変数を修正します。 この際には、以下の 2 つの点に注意しなければなりません。 1 $semihosting_vector 変数が指すアプリケーション・ハンドラ内 の実際の位置が正しくなければなりません。 2 EmbeddedICE インタフェースが SWI をトラップするポイントでは、 アプリケーションの SWI ハンドラが、すべてのレジスタの値を、SWI ハンドラの起動時の値にリストアしていなければなりません。一般 的には、SWI ハンドラがレジスタ値を起動時にスタックに格納し、 セミホスティング・ベクタ・アドレスに進む前にレジスタ値をリス トアすることを意味します。この処理を怠ると、セミホスティング は終了してしまいます。 たとえば、SWI の処理に失敗したことを検出するとエラー・ハンドラに分岐 する SWI ハンドラがあるとします （SWI ハンドラの書き方については、 「ARM ソフトウェア開発ツールキットユーザ・ガイド [ARM DUI 0040]」の「例外 処理」を参照してください）。 ; SWI が処理できれば r0 = 1 にセットする CMP r0, #1 ; SWI が処理できたかどうかをテストする BNE NoSuchSWI ; 未知の SWI ハンドラを呼び出す LDMFD sp!, {r0} ; SPSR をアンスタックして ... MSR spsr, r0 ; ... リストアする LDMFD sp!, {r0-r12,pc}^ ; レジスタをリストアして制御を返す このコードを EmbeddedICE インタフェースのセミホスティングと併用する には、次のように修正します。 ; SWI が処理できれば r0 = 1 にセットする CMP r0, #1 ; SWI が処理できたかどうかをテストする LDMFD sp!, {r0} ; SPSR をアンスタックして ... MSR spsr, r0 ; ... リストアする LDMFD sp!, {r0-r12,lr} ; レジスタをリストアする MOVEQS pc, lr ; SWI が処理できていれば制御を返す Semi_SWI MOVS pc,lr 14 ; EmbeddedICE インタフェース ; ハンドラに進む アプリケーション・ノート31 ARM DAI 0031CJ-00 Open Access Named Partner Confidential - Preliminary Draft セミホスティング そして、Semi_SWI のアドレスを指すように $semihosting_vector 変数 を設定します。EmbeddedICE インタフェースは、セミホスティング SWI の 処理後に直接アプリケーションに制御を返すため、このアドレスの命令は実 行されません。しかしながら、通常の SWI リターン命令を使用することで、 セミホスティング・ブレークポイントが設定されていなくても、アプリケー ションがクラッシュすることを防止できます。要求されたセミホスティン グ・アクションは実行されず、ハンドラは単純に制御を戻します。 アプリケーションがセミホスティング ARM C ライブラリにリンクされてい て、C ライブラリの起動コードを使用している場合には、少し複雑になりま す。アプリケーションが起動する前にアプリケーション SWI ハンドラの一部 へ進むように $semihosting_vector 変数が設定されていると、ライブラ リの起動時に呼び出されたセミホスティング SWI（たとえば、ヒープおよび スタック情報を取得するための SWI）によって、未知のウォッチポイント・ エラーが発生します。 この原因は、この時点ではまだ SWI ベクタにはアプリケーション・ハンドラ がインストールされておらず、ソフトウェア・ブレークポイント・ビット・ パターンが残っている可能性があるためです。この結果、現時点では到達で きない位置に $semihosting_vector アドレスが移動してしまっているた めに EmbeddedICE インタフェースが認識できないブレークポイントがヒッ トしてしまいます。この問題を防止するには、通常はメイン・コードにブ レークポイントを設定することによって、アプリケーションが自分のハンド ラをインストールする直前に $semihosting_vector 変数の内容を変更し ます。 注意 アプリケーションがセミホスティングをまったく必要としない場合には、こ の処理は簡単にできます。単に $semihosting_enabled 変数を 0 に設定 すればよいのです。 したがって、以前に Angel を使用していたアプリケーションを EmbeddedICE ベース・システムに移行する際には注意が必要です。Angel ベースのシステ ムでアプリケーション SWI ハンドラを追加するには、SWI ベクタ（Angel に よってインストールされていたもの）の内容を別の位置に移動（および調整） して、アプリケーション SWI ハンドラを SWI ベクタにインストールするの が一般的です。EmbeddedICE インタフェースでは、SWI ベクタから移動する 命令はありませんので、この方法は正常に機能しません。したがって、アプ リケーション・ハンドラが特定の SWI を処理できない場合には、ストレージ 位置までジャンプして、完全にランダムな命令（通常は未定義）を実行しよ うとします。このため、EmbeddedICE ベース・システムにアプリケーション を移行する場合には、アプリケーション SWI ハンドラとセミホスティング SWIハンドラを正しくインストールするようにコードを修正する必要があり ます。 アプリケーション・ノート31 ARM DAI 0031CJ-00 Open Access 15 ROM でのアプリケーションのデバッグ 8 ROM でのアプリケーションのデバッグ 本セクションでは、EmbeddedICE インタフェース（または Multi-ICE）で ROM のアプリケーションをデバッグする際の問題について説明します。 8.1 リセットからのデバッグ EmbeddedICE インタフェースは、ROM から実行されるシステムをデバッグ するためにも使用できます。ROM にアプリケーションが格納されているター ゲット・ボードに電源が投入されると、アプリケーションが動作を開始しま す。したがって、デバッガがホスト上で起動すると、ターゲット上のプロ セッサは停止します。この段階でアプリケーションがどの実行ポイントにあ るかは、デバッガの起動タイミングによって決まります。 つまり、システムのステートを調べて、アプリケーションの実行を現在の位 置から再開することができます。このような実行再開が必要なケースもあり ますが、多くの場合には、電源投入時の状態からアプリケーションの実行を 再開するほうが適しています。それには 2 つの方法があります。 • • リセットのシミュレーション ターゲットの実際のリセット 「 12.3 リセットおよび JTAG 信号の接続 」の「 基本 nTRST 接続 」で説明 する基本 nTRST 接続を確立している場合には、リセットのシミュレーショ ンのみが可能です。 「 nTRST および nRESET の分離制御」で説明するよう に nlCERST を使用している場合には、どちらの方法も可能です。 ROM から実行されるコードをデバッグする際には、ROM 内のコードに対し てブレークポイントを設定できるように（ソフトウェア・ブレークポイント は使用できないため）、最低 1 つのウォッチポイント・ユニットが利用可能 でなければなりません。セミホスティングやベクタ捕捉を使用しないこと で、デバッガがこれらのユニットを使用してしまう可能性を抑えることがで きます。そのためには、次の 2 つのデバッガ内部変数を、デバッガの起動直 後に設定してください。 $semihosting_enabled = 0 $vector_catch = 0 次に、ROM 外のブレークポイントやウォッチポイントが設定される前に、 ROM 内でブレークポイントを設定します。そうしないと、ウォッチポイン ト・ユニットが占有されていまい、次のエラー・メッセージが出力されて、 ROM 内でブレークポイントを設定できなくなってしまいます。 Error: Too many breakpoints この場合には、ウォッチポイント・ユニットを（ブレークポイントやウォッ チポイントを削除することによって）解放してから、ROM 内でブレークポ イントを設定します。 ROM 内のシステムをデバッグする際のもう 1 つの問題は、ROM イメージに デバッグ情報を含めることができないということです。EmbeddedICE インタ フェースを使用してデバッグを実行する場合には、関連する情報をホスト上 のファイルからデバッガにロードすることによって、シンボルまたはソー ス・コード情報を利用できます。この方法については、「 8.2 デバッグ情報 へのアクセス」を参照してください。 16 アプリケーション・ノート31 ARM DAI 0031CJ-00 Open Access Named Partner Confidential - Preliminary Draft ROM でのアプリケーションのデバッグ リセットのシミュレーション デバッガでリセットをシミュレートするには、以下のように設定します。 PC を 0 に設定 リセット・ベクタのアドレスです。 CPSR を %IF_SVC32 に設定 割込みを無効にしてスーパバイザ・モー ドに移ります。 この結果、ARM の電源投入 / リセット時のステートがシミュレートされます が、メモリ・マップのリセットや、ターゲット特有機能（レジスタなど）の 初期化は実行できません。したがって、このようなターゲット特有の機能は、 アプリケーションを再起動する前に（可能であれば）起動時のコンフィギュ レーションに戻すことをお勧めします。この手順は、デバッガのスクリプト 機能（obey コマンドまたは -script オプション）を使用して自動化するこ ともできます。 実際のリセットの実行 リセット回路の設計によっては、ボードを実際にリセットできる場合もあり ます。しかしながら、EmbeddedICE マクロセルもリセットされてしまうと、 デバッガがマクロセルと同期できなくなるため、リセットを実行する際には 注意が必要です。ボード上では 2 つの形式のリセットが必要です。 • • ボード上のすべての回路をリセットするフル・パワーオン・リセット EmbeddedICE マクロセル以外のボード上のすべての回路をリセット するリセット・ボタン 詳細は、「 12 システム設計に関する注意事項」を参照してください。 リセット・ベクタ上（もしくはリセット・ベクタが分岐する先のリセット・ ルーチンの ROM 内のアドレス）でハードウェア・ブレークポイントが設定 されている場合、ターゲットをリセットすると、必要とされる通りの状態で ターゲットが停止します。EmbeddedICE マクロセルはリセットされません。 また、ブレークポイントは失われます。 注意 ソフトウェア・ブレークポイント / ウォッチポイントはリセットによって失 われますが、デバッガはこれらのポイントが存在するものと考えてしまうた め、リセットを実行する前にこれらのポイントを削除したほうがよいでしょ う。リセット後にこれらのポイントを削除しようとすると、問題が発生する ことがあります。 例 : ARM 開発ボード（PID7T） ARM 開発ボードは、必要とされる 2 レベルのリセットをインプリメントし ます。この場合、リセット・スイッチが初期化リセットを実行するため、リ セットからのデバッグを実行することができます。必要な手順は、ハード ウェア・ブレークポイントを設定してからリセット・ボタンを押すだけです。 アプリケーション・ノート31 ARM DAI 0031CJ-00 Open Access 17 ROM でのアプリケーションのデバッグ 8.2 デバッグ情報へのアクセス 通常（ソフトウェア開発ツールキット 2.50 以降）、armlink はアプリケーショ ン・イメージを ELF 形式で生成します。このイメージを ROM やフラッシュ・ メモリにプログラミングするためには、適切なバイナリ形式に変換しなけれ ばなりません。この作業は fromelf ツールを使用して行います。 変換後のバイナリ・ファイルを ROM にプログラミングしたら、ELF ファイ ルからのデバッグ情報をデバッガにロードすることができます。 armsd の場合 armsd を起動する場合には、次のコマンドを使用します。 armsd -symbols filename.axf armsd がすでに起動している場合には、次のコマンドを使用します。 readsyms filename.axf filename.axf には、armlink が生成した ELF ファイル名を指定します。 ADW/ADU の場合 Fileメニューから Load symbols only を選択し、システム ROMのイメージに 対応する ELF ファイルを選択します。 詳細は、「ARM ソフトウェア開発ツールキットユーザ・ガイド [ARM DUI 0040]」の「ROM コードの書き方」を参照してください。 8.3 ROM が 0x0 にあるシステムのデバッグ RAM ではなく ROM が 0x0 にある ARM7 ベース・システムをデバッグする には、EmbeddedICE インタフェースがベクタ・テーブル上にブレークポイン トを設定してしまわないように、$vector_catch 変数を 0 に設定する必要 があります。 注意 18 Multi-ICE を使用して ARM9 ファミリ・システムをデバッグする場合には、 特別なベクタ捕捉ハードウェアを備えているため、この設定は重要ではあり ません。 アプリケーション・ノート31 ARM DAI 0031CJ-00 Open Access Named Partner Confidential - Preliminary Draft EmbeddedICE マクロセルへの直接アクセス 9 EmbeddedICE マクロセルへの直接アクセス EmbeddedICE マクロセル・レジスタを操作するための新しいデバッガ・コマ ンドは追加されていませんが、コプロセッサ番号を 0 に指定して、コプロ セッサ・レジスタを表示および設定するコマンドを使用することができま す。コプロセッサ 0 は、絶対にインプリメントされないものとして定義され ているため、ユーザまたは ARM が開発したコプロセッサとはクラッシュし ません。 たとえば、armsd の cregisters 0 コマンドは、下記のレジスタの内容を 表示しますが、これらは EmbeddedICE マクロセル・レジスタです。 ARMSD: cregisters 0 c0 = 0x05 c1 = 0x09 c4 = 0x00 c5 = 0x00000000 c8 = 0x516ce8da c9 = 0xbfdf0ea6 c10 = 0xbff6fd7d c11 = 0xfbaffbff c12 = 0x0000 c13 = 0xff c16 = 0x00000008 c17 = 0x00000003 c18 = 0x7dfeeffb c19 = 0xffffffff c20 = 0x0100 c21 = 0xf6 ADW でコプロセッサ 0 レジスタにアクセスするには、View メニューから Registers を選択して Coprocessor ダイアログボックスを表示し、コプロセッ サ番号として 0 を入力してから Raw（未フォーマット）表示オプションを選 択します。 表示されるコプロセッサ 0 レジスタと EmbeddedICE マクロセル・レジスタ との関係は次の通りです。EmbeddedICE マクロセル・スキャン・チェインの register address フ ィ ー ル ド に 表 示 さ れ る 値 は レ ジ ス タ 番 号 で す。 EmbeddedICE マクロセルについての詳細は、デバッグ機能を持つ ARM コア （ARM7DI や ARM7TDMI など）に関するデータ・シートを参照してください。 EmbeddedICE マクロセルのリードは、この方法で自由に行えますが、ライト を実行するには注意が必要です。EmbeddedICE も、ブレークポイントや ウォッチポイントを設定する際に EmbeddedICE マクロセル・レジスタを使 用しているからです。EmbeddedICE マクロセル・レジスタへのライトを （cwrite 0 20 0x44 といった armsd コマンドを使用して）実行すると、 EmbeddedICE は、そのレジスタが関与するブレークポイントが使用中かどう かをチェックします。使用中であれば、EmbeddedICE はそのブレークポイン トを（ハードウェア・ブレークポイントをソフトウェア・ブレークポイント に格下げすることによって）解放し、そのブレークポイントを使用しないよ うにロックします。 アプリケーション・ノート31 ARM DAI 0031CJ-00 Open Access 19 EmbeddedICE マクロセルへの直接アクセス こ の 方 法 で ロ ッ ク さ れ て い る ブ レ ー ク ポ イ ン ト を 調 べ る に は、 $icebreaker_lockedpoints 変数の値を表示します。このデバッガ内部 変数の値を変更することによって、ブレークポイントのロックを解除するこ とができます。ARM7DI および ARM7TDI では、ブレークポイントに 1 およ び 2 の番号が付けられ、$icebreaker_lockedpoints 変数のビット 1 お よび 2 がそれぞれのステータスを表します。 この方法で設定されているブレークポイントやウォッチポイントが成立し た場合、EmbeddedICE は、（自分が認識しているブレークポイント / ウォッ チポイントではないため）実行が停止した理由を知ることができず、未知の ウォッチポイントをレポートしてターゲットの実行を停止します。 EmbeddedICE は、ユーザがプログラミングしたウォッチポイントでは実行を 停止することができないため、デバッガ・ハードウェア・ウォッチポイント と、ユーザがプログラミングした EmbeddedICE ウォッチポイント・ユニッ トを併用してはいけません。実際には、EmbeddedICE マクロセルはウォッチ ポイントを 2 個しか持たず、2 番目のウォッチポイントは直接プログラミン グできるため、これを原因とする問題はあまり発生しません。 EmbeddedICE マクロセル・レジスタ 0 および 1（コントロールおよびステー タス・レジスタ）へのライトを実行する際には注意が必要です。EmbeddedICE は、多くの動作でこれらのレジスタを使用します。これらのレジスタに対し てライトを実行した場合には、後で必ず元の値に戻してください。 EmbeddedICE マクロセル・レジスタをリードまたはライトするデバッガ要求 が出されても、必ずしもレジスタがただちにリードまたはライトされるとは 限りません。EmbeddedICE のソフトウェアは、処理効率を向上させるため、 EmbeddedICE マクロセル・レジスタに内容をキャッシュし、ターゲット・シ ステムの実行が再開される前にのみ、変更されているレジスタを更新するた めです。 20 アプリケーション・ノート31 ARM DAI 0031CJ-00 Open Access Named Partner Confidential - Preliminary Draft タイマ精度 10 タイマ精度 EmbeddedICE インタフェースまたは Multi-ICE を使用すると、標準 ANSI の clock() 関数が不正確になることがあります。 この理由は次の 2 つです。 • • Angel SWI SWI_CLOCK（標準 ANSI の clock() ルーチンによって呼 び出されます）の EmbeddedICE エージェントと Multi-ICE 内でのイ ンプリメンテーションの精度は、1/100 秒ではなく 1 秒であるのに、 CLK_TCK （1秒あたりのクロック・ティック数）の値は100となります。 EmbeddedICE エージェントも Multi-ICE も、現時点では自身でタイ ミング値を送信せず、そのかわりに、ホストに対して要求を送りま す。つまり、EmbeddedICE インタフェースがホストに要求を送って ホストから値が返されるまでの時間が加算されるため、返される値 は実際より大きくなります。 これらの要因が組み合わさって、EmbeddedICE ベース・システムのベンチ マーク（Dhrystone など）の結果は不正確になります。これらのケースでは 十分な注意が必要です。不正確さの影響を最小限に抑えるためには、非常に 多くの回数のベンチマークを繰り返さなければなりません。アプリケーショ ンを修正して、ボード上で動作しているタイマ・ルーチンから値を取るク ロック・ルーチンを使用するようにすれば、より正確な結果が得られます。 ARM 開発ボード（PID7T）で提供されているサンプル群には、オンボード・ タイマ割込みからタイマ値が生成されるようにした Dhrystone バージョンが 含まれています。このサンプルは、ARM の Web サイトからダウンロードす ることもできます。 アプリケーション・ノート31 ARM DAI 0031CJ-00 Open Access 21 ターゲット・ボードのメモリ・レイアウト ターゲット・ボードのメモリ・レイアウト 11 デバッガ変数の $top_of_memory は、EmbeddedICE インタフェースによっ てリードされ、リード・ライト・メモリの先頭を指定します。また、この変 数値は Angel の heap_info SWI によって返され、C ライブラリが初期に使 用します。 $top_of_memory のデフォルト値は512KB で、 RAMが増設されていない ARM 開発ボード（PID7T）には適しています。RAM を増設したか、RAM 量が多 い（または少ない）ボードを使用している場合には、$top_of_memory 変数 を正しい値に変更してから、アプリケーションを実行してください。 このメカニズムは、アプリケーション・ヒープをアプリケーション・プログ ラムより上に配置し、アプリケーション・スタックをメモリの先頭に配置し ます。また、アプリケーションの終端からメモリ先頭まで、メモリが連続し ている必要があります。 メモリが連続していない場合には、アプリケーションで次のシンボルを定義 して、このメカニズムを無効にし、アプリケーション・ヒープとスタックを 正確に設定することができます。 __heap_base,__heap_limit,__stack_base,__stack_limit. たとえば、ARM アセンブラでは次のように指定します。 EXPORT __heap_base __heap_base DCD my_heapbase_value 11.1 特権モードとスタック・ポインタ EmbeddedICE インタフェース自身はスタック・ポインタを設定しません。し たがって、完全にセミホスティングされている ANSI C ライブラリとリンク した場合には、現在のモード用に設定されたスタック・ポインタが与えられ ますが（「 11 ターゲット・ボードのメモリ・レイアウト」参照）、他のモー ド用に設定されたスタック・ポインタは与えられません。これは、ARMulator や Angel でアプリケーションを実行した場合にスタックが自動的に設定され るのとは対照的です。 このため、アプリケーションの起動コードでは、（たとえば、成立した例外 の結果として）入る可能性のあるすべてのモードに対して、スタック・ポイ ンタを設定する必要があります。 完全にセミホスティングされている ANSI C ライブラリとリンクしない場合 には、現在のモード用のスタック・ポインタも設定されません。 詳細は、 「ARM ソフトウェア開発ツールキット・バージョン 2.50 ユーザ・ガ イド [ARM DUI 0040D]」の「ROM コードの書き方」を参照してください。 22 アプリケーション・ノート31 ARM DAI 0031CJ-00 Open Access Named Partner Confidential - Preliminary Draft システム設計に関する注意事項 12 システム設計に関する注意事項 本セクションでは、EmbeddedICE インタフェースを使用してデバッグするシ ステムを設計する際の注意事項について解説します。 12.1 メモリ・アクセス条件 背景情報 ターゲット・デバイス内の EmbeddedICE マクロセルには、2 個のウォッチポ イント・ユニットがあり、それぞれをブレークポイントまたはウォッチポイ ントとしてプログラミングできます。本セクションでは、メモリ内でブレー クポイントをどのように設定するかについて説明します。 ブレークポイントを ROM で設定すると、EmbeddedICE マクロセルのブレー クポイント・ユニットの片方を占有します。この場合、ブレークポイント対 象の命令の ROM アドレスが、EmbeddedICE インタフェースによって、マク ロセルのアドレス値レジスタにプログラミングされます。このマクロセルユ ニットは、プログラミングされているアドレスの命令が ROM からフェッチ されて命令パイプラインの実行ステージに達した時点で、命令の実行を停止 します。 RAM の命令に対してブレークポイントを設定する場合は、処理は少し複雑 になりますが、ROM の場合よりも強力なブレークポイント機能が実現され ます。RAM では、ブレークポイントを設定する各アドレスに対してマクロ セルのブレークポイント・ユニットが占有されることはなく（ROM の場合 は占有されます）、RAM 内の命令が EmbeddedICE インタフェースによって 未使用のビット・パターンで書き換えられます。未使用パターンで書き換え られた命令は、ホストのデバッグ・プラットフォームに格納され、RAM の ブレークポイントに到達したりブレークポイントが削除されたりした時点 で、未使用パターンを書き換えます。RAM のブレークポイントの場合には、 常に同じパターンが検索されるため、1 つのブレークポイント・ユニットを 使用するだけで、ブレークポイントをいくつでも設定することが可能です。 RAM のブレークポイントは、EmbeddedICE によるデバッグを強化します。 また、書き換えられた命令はデバッガのメモリに格納されるため、ターゲッ トのリソースを使用しません。 メモリ内で ARM 命令に対してブレークポイントを設定する場合にや、ARM 命令セットの未使用ビット・パターンである 0xdeeedeee を使用します。Thumb の命令（16 ビット命令）に対してブレークポイントを設定する場合には、 Thumb 命令セットの未使用ビット・パターンである 0xdeee を使用します。 設計条件 ワード・メモリ・アクセスはほとんどすべての ARM システムでサポートさ れているため、ARM 命令ブレークポイントの設定には何も問題ありません。 しかしながら、RAM の Thumb 命令で必要とされる 16 ビットのリード / ライ ト・オペレーションは、実際には 1 回のハーフワード・アクセスではなく、 2 バイト・アクセスを使用して実行されます。したがって、バイト幅のメモ リを使用しないメモリ・システムであっても、ワード・アクセスとバイト・ アクセスの両方をサポートする必要があります。 注意 バイト・アクセスのサポートは、別の理由からも重要です。バイト・アクセ スは ARM アーキテクチャの重要な要素であり、パック・ストラクチャの操 作、キャラクタ・ストリングのアクセス、メモリへのデバッガ・アクセスな ど、いろいろな操作において、ARM ツールは常にバイト・アクセスが可能 であるものと想定しています。 アプリケーション・ノート31 ARM DAI 0031CJ-00 Open Access 23 システム設計に関する注意事項 注意 12.2 Multi-ICE リリース 1.3（以降）は、ハーフワード命令を使用して Thumb の ソフトウェア・ブレークポイントを設定します。それでもなお、バイト・ア クセスのサポートは強く推奨されます。 ARM ターゲット・ボードとの接続 本セクションでは、EmbeddedICE インタフェースと ARM ターゲット・ボー ドとの物理接続について解説します。 注意 Multi-ICE を使用している場合には、 「Multi-ICE ユーザ・ガイド [ARM DUI 0048]」を参照してください。 EmbeddedICE インタフェースのコネクタ・ピン配列 ターゲット・ボード側のインタフェース・コネクタ（下図参照）は、14 芯の ボックス・ヘッダです。「 図 12-1: EmbeddedICE インタフェース・コネク タ PL1（上から観た図） 」を参照してください。 このプラグは、両端に IDC ソケットが付いた短い 14 芯 IDC ケーブルを使用 して、EmbeddedICE インタフェース・モジュールに接続されます。 図 12-1: EmbeddedICE インタフェース・コネクタ PL1（上から観た図） 24 アプリケーション・ノート31 ARM DAI 0031CJ-00 Open Access Named Partner Confidential - Preliminary Draft システム設計に関する注意事項 「表 12-1: EmbeddedICE インタフェースコネクタ PL1 」に、各コネクタ・ ピンの機能を示します。 ピン 名 機能 1 SPU システム電源投入、33 オーム抵抗を介して Vdd に接続 3 nTRST テスト・リセット、アクティブ・ロー 5 TDI テスト・データ入力 7 TMS テスト・モード選択 9 TCK テスト・クロック 11 TDO テスト・データ出力 12 nICERST ターゲット・システム リセット（nSYSRST または nRSTOUT とも呼ばれる） 13 SPU システム電源投入、33 オーム抵抗を介して Vdd に接続 2, 4, 6, 8, 10, 14 VSS システム接地参照（ノイズを最小限に抑えるため、すべ ての VSS ピンを接続すること） 表 12-1: EmbeddedICE インタフェースコネクタ PL1 これらの信号の機能は明確ですが、一部は特別な機能を持っています。 TDI、TDO、TMS、TCK、および nTRST は、標準 5 線 JTAG インタフェース信 号です。 nICERST は、デバッガからターゲット・システムをリセットするための機能 ですが、EmbeddedICE インタフェースではサポートされていません。他のプ ロトコル・コンバータ（Multi-ICE など）はこの機能を使用するため、可能 であれば、リセット回路にこの信号を組み込んでください。 SPU は、EmbeddedICE がターゲット・システムの正電圧を監視して、JTAG ラ インがドライブされてターゲット互換ロジックによって受信されることを 保証するために使用されます。 アプリケーション・ノート31 ARM DAI 0031CJ-00 Open Access 25 システム設計に関する注意事項 EmbeddedICE インタフェース・ドライバ / レシーバ回路 適切なインタフェース・セルを選択できるように、EmbeddedICE インタ フェース内部の実際のドライバ / レシーバ回路を以下に示します。 • EmbeddedICE インタフェースからの出力 JTAG 出力（TDI、TMS、TCK、および nTRST）は、74HC14 シュ ミ ッ ト・トリガ・インバータ・デバイスからドライブされます。 74HC14 デバイスへの電源は、ターゲット・システムからの SPU 信 号から派生し、ドライバとターゲット・システムとの電圧レベル互 換性を保証します。 図 12-2: EmbeddedICE インタフェース出力回路 • EmbeddedICE インタフェースへの入力 JTAG 入力（TDO）は、47 オームの直列抵抗と、その後の 10K オー ムの並列プルダウン抵抗によって終端されます。この終端入力は、別 の 74HC14 デバイスに供給されます。このデバイスも、SPU 信号か らの電源供給によって、電圧レベルの互換性が保証されます。 図 12-3: EmbeddedICE インタフェース入力回路 26 アプリケーション・ノート31 ARM DAI 0031CJ-00 Open Access Named Partner Confidential - Preliminary Draft システム設計に関する注意事項 12.3 リセットおよび JTAG 信号の接続 ターゲット・システムを設計する際には、JTAG およびリセット信号について 考慮する必要があります。使用できるアプローチについて以下に説明します。 nRESET は、プロセッサ・コアをリセットして既知ステートに入れます。 nTRST は、TAP コントローラと EmbeddedICE マクロセル（ブレークポイント / ウォッチポイント・ユニットのレジスタを含む）をリセットします。これ らのリセットを実行しないと、デバイスは正常に動作しません。 システムは、EmbeddedICE インタフェースが接続されていても接続されてい な く て も、正 常 に 動 作 す る よ う に 設 計 し な け れ ば な り ま せ ん。ま た、 EmbeddedICE インタフェースによって JTAG TAP と、場合によってはシステ ム自身をリセットできるように設計してください。 以下に、nTRST 信号を生成するための 2 つのアプローチについて説明しま す。最初のアプローチは、シンプルで、基本的なリセット・スキーマを実現 するものです。2 番目のアプローチは、やや複雑で、デバッガによる強力な 制御を可能にするものです。 基本 nTRST 接続 EmbeddedICE インタフェースが接続されていない状態でもシステムは正常 に機能しなければならないため、以下の条件を満足させなければシステムは 動作しません。 • • nRESET は、数クロックの間“Low”を保ってから、 “High”に遷移 してプロセッサをリセット・ステートから解放しなければなりませ ん（詳細は、関連するプロセッサのデータ・シート参照）。 nTRST は、TAP がリセットされるまで“Low”を保たなければなり ません。このための方法は次の通りです。 - nTRST を永続的に“Low”に接続する - nTRST を“Low” に保ってから“High”に遷移させる しかしながら、nTRST を永続的に“Low”に接続した場合には、JTAG ポー トによるデバッグは実行できません。したがって、nTRST は、パルスによっ て“Low”に保たなければなりません。最も簡単な方法は、nTRST を直接 nRESET に接続することです プロセッサ TCK, TDI, TMS, TDO TCK, ... nTRST EmbeddedICE コネクタ リセット 制御 nRESET 図 12-4: 基本 nTRST 接続 アプリケーション・ノート31 ARM DAI 0031CJ-00 Open Access 27 システム設計に関する注意事項 TAP は TCK および TMS 信号の組み合わせだけでリセットできるため、この 構成でも EmbeddedICE インタフェースは TAP をリセットできます。このア プローチのデメリットは、リセット後のプロセッサに対してブレークポイン トを設定することができないということです。これは、プロセッサがリセッ トされているときは TAP も常にリセットされ、TAP がこのステートにある ときはブレークポイント・レジスタをプログラミングできないためです。 nTRST および nRESET の分離制御 プロセッサがリセットから抜け出した時点でターゲット・システムが停止す るように、リセット・ベクタ上でブレークポイントを設定できることが求め られる場合もあります。 しかしながら、この場合にはプロセッサがリセットから抜け出る前にブレー クポイント・レジスタをプログラミングしなければならず、nTRST 信号と nRESET 信号を分離して制御しなければなりません。 「図 12-5: nTRST と nRESET の接続 」に、推奨される接続方式を示します。 この方式では、リセット制御ロジック（シンプルな PLD でも可）を使用し てリセットをドライブし、初期電源投入時にのみ nTRST を“Low”に保っ ています。nRESET は、電源投入時とリセット時の両方に“Low”に保たれ ます。 プロセッサ TCK, TDI, TMS, TDO TCK, ... nTRST EmbeddedICE コネクタ リセット 制御 nRESET 図 12-5: nTRST と nRESET の接続 このアプローチでは、アドレス 0 にブレークポイントを設定してからリセッ ト・ボタンを押すことで、リセット・ブレークポイントを設定することがで きます。 「 基本 nTRST 接続」で説明した基本方式を使用している場合には、 リセット・ボタンを押すことで、ブレークポイント・レジスタもリセットさ れてしまいます。 EmbeddedICE コネクタには、EmbeddedICE がターゲット・システムをリセッ トするときにアサートする nICERST 信号もあります。「 図 12-6: nTRST、 nRESET、および nICERST の接続」を参照してください。 28 アプリケーション・ノート31 ARM DAI 0031CJ-00 Open Access Named Partner Confidential - Preliminary Draft システム設計に関する注意事項 プロセッサ EmbeddedICE コネクタ TCK, TDI, TMS, TDO TCK, ... nTRST nICERST リセット 制御 nRESET 図 12-6: nTRST、nRESET、および nICERST の接続 注意 • • 12.4 一部の EmbeddedICE 関連文書では、nICERST 信号は nSYSRST と 呼ばれています。 EmbeddedICE インタフェースを使用している場合には、デバッガか らターゲット・システムをリセットすることはできません。Multi-ICE を使用している場合には、適切に設計されたターゲット・システム をデバッガからリセットすることができます。詳細は、 「Multi-ICE ユーザ・ガイド [ARM DUI 0048]」を参照してください。 その他の注意事項 デバッガが起動すると、EmbeddedICE マクロセルを（スキャン・チェイン 2 を通して）プログラミングして DBGRQ をアサートすることにより、ARM コアを停止しようとします。しかしながら、デバッガがこのプロセスに失敗 し、Target Processor not stopped というエラー・メッセージを出力 したり、デバッグ・セッションにおいて誤動作したりすることがあります。 このプロセスを正常に実行するためには、以下の条件を満足していなければ なりません。 1 コアがデバッグ・ステートに入るためには、DBGEN が“High”に接 続されていなければなりません。 2 デバッガが正しいプロセッサを使用するように設定されていなけれ ばなりません。デフォルトでは、EmbeddedICE インタフェースは （ARM7DI ではなく）ARM7TDI を使用します。 3 コアへのクロック（MCLK）が（インフィニット・ウェイト・ステー トなしで）動作中でなければなりません。 4 ARM がバス・マスタでなければなりません。 5 EmbeddedICE インタフェースを使用する場合には、 MCLK が 100KHz を超えていなければなりません。 6 コアとマクロセルが（上述のように）正しくリセットされていなけ ればなりません。 アプリケーション・ノート31 ARM DAI 0031CJ-00 Open Access 29 システム設計に関する注意事項 30 アプリケーション・ノート31 ARM DAI 0031CJ-00 Open Access Named Partner Confidential - Preliminary Draft
© Copyright 2026 Paperzz
