JP2003263335A - デバッグモニター - Google Patents

Abstract

(57)【要約】 【課題】 ファームウエア部の例外処理中でもデバッグ
を可能にしたデバッグモニターを得る。 【解決手段】 例外処理のデスパッチ機能をソフト的に
行うＲＩＳＣ−ＣＰＵとして構成されたＣＰＵ１と、オ
ペレーティングシステムやモニターのプログラムを入れ
るＲＯＭ２と、データ領域に使用されるリードアンドラ
イトメモリ３と、オペレーティングシステムのタスク切
り替えや時間管理に使用し定期的にタイマー割り込みを
発生させるタイマーモジュール５と、外部のターミナル
８との間でデータのやり取りを行うのに使用するシリア
ルモジュール６と、モニターコマンドやデータダンプ用
に使用する、一般的にはログデータの表示等に使用する
モニターとを有して構成される。上記の構成によれば、
ＲＩＳＣ−ＣＰＵ用のモニターに対して、ＲＴＯＳまた
はＯＳと同期してモニター機能を使用することが可能と
なる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、デバッグモニター
に関し、特に、制御装置としてＲＴＯＳ（リアルタイム
・オペレーティング・システム）または、ＯＳ（オペレ
ーティング・システム）を用いた組込み機器の開発環境
に適用されるデバッグモニターに関する。

【０００２】

【従来の技術】従来、デバッグモニターは、一般に、フ
ァームウエア部の開発において、プログラムの誤りであ
るバグを発見して修正作業を行う際に支援するために用
いられる。

【０００３】従来、ＲＴＯＳ（リアルタイム・オペレー
ティング・システム）または、ＯＳ（オペレーティング
・システム）のファームウエア部の開発を行う場合、Ｉ
ＣＥ（インサーキット・エミュレータ）を用いて、組込
み機器ボードをＣＰＵのラインから監視・トレースしな
がら開発を行う手法が適用される。

【０００４】図６は、ＲＴＯＳ実行時の例外プログラム
と、モニター実行時の例外プログラムであり、従来のモ
ニターとオペレーティングシステムでの例外処理の実行
形態を示している。このような形態の開発環境では、電
源投入時にモニターが起動する。このモニターは、ファ
ンクションポインターテーブル上に自分用の例外処理プ
ログラムを配置して、例外のハンドリングを行う。

【０００５】本発明と技術分野の類似する先願発明例１
として、特開２０００−２８４９８０号公報のメッセー
ジ伝送スケジューリング方法に関する発明がある。本先
願発明例１では、システムが必ずしもリアルタイム機能
を備えない標準型の出来合いのコンポーネントで構成さ
れている場合でも、ユーザがアクチビティのリアルタイ
ムスケジューリングを指定できるようなマルチタスクシ
ステムおよびマルチタスクシステムにおけるメッセージ
伝送スケジューリング方法を提供できる、としている。

【０００６】先願発明例２の特開平６−８９２００号公
報の「デバッグシステム及び方法」では、大規模で複雑
な生め込み型アプリケーションを開発する上で役に立
つ、デバッグシステムを提供することを目的としてい
る。

【０００７】先願発明例３の特開平９−５０４８９６号
公報の「オブジェクト指向グラフィック・システム」
は、完全に拡張可能なシステムであり、サポート・オブ
ジェクトの各々に組み込まれた多機能処理機能を備えた
技術に関するものである。

【０００８】

【発明が解決しようとする課題】しかしながら、上記従
来の技術では、モニターからオペレーティングシステム
に実行権をわたすと、オペレーティングシステムは、初
期化時にファンクションポインターテーブルをオペレー
ティングシステム用のものに書き換えてしまう。このた
め、モニターを分岐することができず、モニター用のト
レースやダンプ機能を使うことができない。

【０００９】このような状況において、ＣＰＵのクロッ
クアップやハードウエアの集積化が進み、これらが組込
み用機器のコントローラに対応してくるにつれて、ＩＣ
Ｅでの実動作環境ではエミュレーションができなくなっ
たり、ＩＣＥ自体が高価なものになってしまう。

【００１０】加えて、ＲＴＯＳやＯＳ（オペレーティン
グシステム）上のデバッグ環境の充実によって、ＩＣＥ
を用いなくても、オペレーティングシステム上のデバッ
グは可能となってきた。その反面、オペレーティングよ
りも、よりハードウエアに近い部分の実機開発は、オペ
レーティングシステムのデバッカが使用できず、また、
ＩＣＥも使用できない状況になり、開発はより困難にな
ってしまう問題点を伴う。

【００１１】本発明は、ファームウエア部の例外処理中
でもデバッグを可能にしたデバッグモニターを提供する
ことを目的とする。

【００１２】

【課題を解決するための手段】かかる目的を達成するた
め、本発明のデバッグモニターは、例外処理のデスパッ
チ機能をソフト的に行うＲＩＳＣ−ＣＰＵとして構成さ
れたＣＰＵと、オペレーティングシステムやモニターの
プログラムを入れるリードオンリーメモリであるＲＯＭ
と、データ領域に使用されるリードアンドライトメモリ
と、各デバイスのデータが流れるデータバスと、オペレ
ーティングシステムのタスク切り替えや時間管理に使用
し、定期的にタイマー割り込みを発生させるタイマーモ
ジュールとを有して構成され、前記ＲＩＳＣ−ＣＰＵ上
でＲＴＯＳまたはＯＳ部と同期して例外処理部のデバッ
グを可能としている。

【００１３】従来ＲＩＣＳ−ＣＰＵでは、例外処理のハ
ンドリングをプログラム記述しなければならなく、オペ
レーティングシステムと同期を取る手法がＣＩＳＣ−Ｃ
ＰＵとは異なるが、上記の構成によれば、ＲＩＳＣ−Ｃ
ＰＵ用のモニターに対して、ＲＴＯＳまたはＯＳと同期
してモニター機能を使用することが可能である。

【００１４】また、ＣＩＳＣ−ＣＰＵ上で前記ＲＴＯＳ
またはＯＳ部と同期して、前記例外処理部のデバッグを
可能とする。

【００１５】従来のＣＩＳＣ−ＣＰＵでは、例外処理の
ハンドリングは、ハードウエアが行い、ソフトウエアは
介在せず、オペレーティングシステムと同期を取る手法
がＲＩＳＣ−ＣＰＵとは異なる。しかし上記によれば、
ＣＩＳＣ−ＣＰＵ用のモニターに対して、ＲＴＯＳまた
はＯＳと同期してモニター機能を使用することが可能で
ある。

【００１６】上記ＲＴＯＳまたはＯＳ部と同期して前記
例外処理部のデバッグが可能なモニターを含む、前記Ｒ
ＩＳＣ−ＣＰＵを用いた組込み機器として構成するとよ
い。

【００１７】上記によれば、モニターを組込み機器に組
込むことにより、例外処理部でもモニター機能を使用す
ることが可能である。

【００１８】

【発明の実施の形態】次に、添付図面を参照して本発明
によるデバッグモニターの実施の形態を詳細に説明す
る。図１から図５を参照すると、本発明のデバッグモニ
ターの一実施形態が示されている。

【００１９】図１は、実施形態のデバッグモニターの構
成例を示すブロック図である。図１のデバッグモニター
は、ＣＰＵ１、ＲＯＭ２、リードアンドライトメモリ
３、データバス４、タイマーモジュール５、シリアルモ
ジュール６、ドライバー７、を有して構成される。本構
成のデバッグモニターのドライバ−７とターミナル８と
が接続される。

【００２０】図１は、本発明の達成に必要な最低限度の
ブロック図である。ＣＰＵ１は、この説明では例外処理
のデスパッチ機能をソフト的に行う必要があるＲＩＳＣ
−ＣＰＵを想定している。ＲＯＭ２は、オペレーティン
グシステムやモニターのプログラムを入れるリードオン
リーメモリである。リードアンドライトメモリ３は、デ
ータ領域に使用する。ボードのデータバス４には、各デ
バイスのデータが流れる。タイマーモジュール５は、オ
ペレーティングシステムのタスク切り替えや時間管理に
使用し、定期的にタイマー割り込みを発生させる。モニ
ターでは使用しない。

【００２１】シリアルモジュール６は、外部のターミナ
ル８との間でデータのやり取りを行うのに使用する。モ
ニターは、モニターコマンドやデータダンプ用に使用す
るオペレーティングシステムでは必須ではないが、一般
的にはログデータの表示等に使用する。外部のターミナ
ル８は、ＲＳ２３２Ｃ等の信号を使用するため、内部の
シリアルモジュールとは電圧が異なる。そこでドライバ
ー７を使用して、電圧の調整を行う。

【００２２】上に示す本実施形態のデバッグモニター
は、古くからベーシックな部分の開発、およびデバッグ
に用いられできたモニターに、オペレーティングシステ
ムと同期を取りながら動作する改造が加えられている。
このことにより、ファームウエア部の例外処理中でもデ
バッグを可能とし、組込み機器製品の開発工数を削減可
能としている。

【００２３】なお、上記の例外処理とは、ＣＰＵが発行
する例外処理のことであり、オペレーティングシステム
からは非コンテクストスイッチング部とよばれ、オペレ
ーティングシステムが管理するタスク部分とは実行形態
が大きく異なる。このため、オペレーティングシステム
の開発ツールでは、トレースができないプログラムであ
る。

【００２４】また、本実施形態でのモニターとは、オペ
レーティングシステムが無い環境で、シリアルデバイス
を用いたコンソールを通して、メモリのダンプやセッ
ト、プログラムのトレースを行うプログラム群を装備す
る。これは、オペレーティングシステムが起動すると、
実行環境が異なるために使用できなくなるからである。

【００２５】図２は、例外処理の分類例を示す。また、
図３は、ＲＴＯＳ実行時の例外処理の実行形態例を示し
ている。例外処理には、ＣＰＵ１の動作に連動して発生
するエクセプションと、ＣＰＵ１の外部のモジュールが
ＣＰＵ１に対して情報伝達を行うために発生させる割り
込みとがある。

【００２６】上記のエクセプションには、アドレスエラ
ー、バスエラー、コプロセッサエラー、ＮＭＩ例外、シ
ステムコール、ブレークポイント等、種々のものがあ
る。しかし、本モニターでは、トレース用にブレークポ
イントエクセプションを使用しているが、その他のエク
セプションには対応していない。オペレーティングシス
テムでは、種々のサービスを行う為に、その他のエクセ
プションのハンドリングを行っている。

【００２７】割り込みに関しては、図１のブロック図で
は、タイマー５とシリアルモジュール６のみしかサポー
トを行っていないため、この２つの割り込みしか発生し
ないと想定する。

【００２８】タイマー５は、オペレーティングシステム
では時分割処理を行うために必須のモジュールである。
しかし、モニターでは、タイマー機能を必要としない。
シリアルモジュールは、モニターにおいてはオペレータ
とコマンドレベルで通信を行うための必須のデバイスで
あるが、オペレーティングシステムでは必須ではない。
しかし、ログの表示等、開発時は良く使うデバイスであ
る。ここでは、これらの例外処理プログラムへのハンド
リングは、ＲＡＭ３上の固定のアドレスにファンクショ
ンポインターテーブルの形で配置されていて、モニター
プログラムからもオペレーティングシステムからも参照
が可能な形態であることを想定している。

【００２９】図４は、ＲＩＳＣ−ＣＰＵを対象とした場
合の、例外処理のデスパッチプログラム例を示すフロー
チャートである。デスパッチプログラムとは、ＣＰＵか
ら例外の発生があった場合、その要因を調べ、ファンク
ションポインターテーブルから対応した例外プログラム
を探してそれを実行するプログラムである。オペレーテ
ィングシステムにも、モニターにも例外処理を取り扱う
ため必須のプログラムである。

【００３０】例外のエントリ後のステップＳ１の“現状
のレジスタ等の情報をセーブ”において、例外発生前の
レジスタ、ステータスの状態をスタック上にセーブを行
う。これは、例外処理終了時にこれらの状態を元に戻し
て終了しないと、例外発生前のプログラムが正常に動作
できないからである。なお、元にもどす作業は、ステッ
プＳ５のセーブした現状のレジスタ等の再設定にて行
う。

【００３１】ステップＳ２の“例外の発生原因を調べ
る”で例外の発生原因を調べて、ステップＳ３にて発生
原因に対応した例外処理プログラムをファンクションポ
インターテーブルから取り出して、それを実行させる。

【００３２】ステップＳ４、Ｓ６は、モニターの例外処
理のデスパッチプログラムにはなく、直接ステップＳ５
の状態の復元を行って処理を終了する。オペレーティン
グシステムでは、各例外処理プログラムの中で、タスク
のスイッチングの要求が発生した場合は、例外処理の終
了時に現状のタスクを停止させ、要求のタスクを再起動
する処理が必要となる。これは、ステップＳ４のスイッ
チング要求の確認と、要求があった場合、ステップＳ６
のスイッチングによって実行される。

【００３３】図３は、本発明のモニターの例外処理の実
行形態を示している。モニターからオペレーティングシ
ステムに実行権を渡しても、ファンクションポインター
テーブル上のモニター用のブレークエクセプションプロ
グラムやモニター用のシリアル割り込みプログラムへの
ベクターは書き換えない。

【００３４】オペレーティングシステムが実行状態にな
り、ターミナル上にCtrl-A等のアボート要求のコマンド
を発行すると、ＣＰＵ上でシリアル割り込みが発生す
る。これは、オペレーティングシステム用の例外処理の
デスパッチプログラムを通して、モニター用のシリアル
割り込みプログラムを実行する。

【００３５】このシリアル割り込みプログラムは、モニ
ター用のアボートコードを判別して、モニターのアボー
ト処理に分岐する。モニターのアボート処理は、シリア
ル以外の割り込みを禁止し、ターミナル上にコマンドプ
ロンプトを表示して、モニターコマンド待ち状態となり
モニターの各機能を実行することが可能となる。

【００３６】トレースを行う場合でも、オペレーティン
グシステム用の各例外処理プログラム上にブレークポイ
ントを配置しても、モニターの通常の処理では、オペレ
ーティングシステム用の各例外処理を通過することがな
いので、問題無くトレースが可能である。但し、デスパ
ッチプログラム上にブレークポイントを配置するとシリ
アルの割り込み等でここを通過するので、ハングアップ
状態となる。

【００３７】図５は、ＣＩＳＣ−ＣＰＵの場合の例外処
理デスパチャーのフローチャートである。例外発生に伴
い、ハードウエアがファンクションポインターテーブル
を直接参照して、各例外処理プログラムに分岐する。こ
の場合、レジスタ等のセーブ、リストアー処理は各例外
処理プログラムの中で行われる。

【００３８】モニターでは、リストアーを行った後、例
外処理を終了するが、オペレーティングシステムでは、
共通のコンテキストスイッチングプログラムに飛び込
み、必要ならばタスクのスイッチングを行う。

【００３９】ＣＩＳＣ−ＣＰＵの場合でも、ブレークエ
クセプション例外処理とシリアル例外処理をモニター用
のものにリンクするようにすれば、ＲＩＳＣ−ＣＰＵの
場合と同等に、オペレーティングシステム上でのモニタ
ー処理が可能となる。

【００４０】

【発明の効果】以上の説明より明らかなように、本発明
のデバッグモニターは、例外処理のデスパッチ機能をソ
フト的に行うＲＩＳＣ−ＣＰＵとして構成され、オペレ
ーティングシステムやモニターのプログラムをリードオ
ンリーメモリに入れ、リードアンドライトメモリをデー
タ領域に使用し、データバスには各デバイスのデータが
流れ、オペレーティングシステムのタスク切り替えや時
間管理に使用し、定期的にタイマー割り込みを発生さ
せ、ＲＩＳＣ−ＣＰＵ上でＲＴＯＳまたはＯＳ部と同期
して例外処理部のデバッグを可能としている。

【図面の簡単な説明】

【図１】本発明のデバッグモニターの実施形態の構成例
を示すブロック図である。

【図２】例外処理の分類例を示す図である。

【図３】ＲＴＯＳ実行時の例外処理の実行形態例を示し
ている。

【図４】ＲＩＳＣ−ＣＰＵを対象とした場合の例外処理
のデスパッチプログラム例を示すフローチャートであ
る。

【図５】ＣＩＳＣ−ＣＰＵの場合の例外処理デスパチャ
ーのフローチャートである。

【図６】ＲＴＯＳ実行時の例外プログラムと、モニター
実行時の例外プログラムであり、従来のモニターとオペ
レーティングシステムでの例外処理の実行形態を示して
いる。

【符号の説明】

１ ＣＰＵ ２ ＲＯＭ ３ リードアンドライトメモリ ４ データバス ５ タイマーモジュール ６ シリアルモジュール ７ ドライバー ８ ターミナル

Claims (3)

【特許請求の範囲】
1. 【請求項１】 例外処理のデスパッチ機能をソフト的に
   行うＲＩＳＣ−ＣＰＵとして構成されたＣＰＵと、 オペレーティングシステムやモニターのプログラムを入
   れるリードオンリーメモリであるＲＯＭと、 データ領域に使用されるリードアンドライトメモリと、 各デバイスのデータが流れるデータバスと、 オペレーティングシステムのタスク切り替えや時間管理
   に使用し、定期的にタイマー割り込みを発生させるタイ
   マーモジュールとを有して構成され、 前記ＲＩＳＣ−ＣＰＵ上でＲＴＯＳまたはＯＳ部と同期
   して例外処理部のデバッグを可能としたことを特徴とす
   るデバッグモニター。
2. 【請求項２】 前記ＣＩＳＣ−ＣＰＵ上で前記ＲＴＯＳ
   またはＯＳ部と同期して、前記例外処理部のデバッグを
   可能としたことを特徴とする請求項１記載のデバッグモ
   ニター。
3. 【請求項３】 前記ＲＴＯＳまたはＯＳ部と同期して前
   記例外処理部のデバッグが可能なモニターを含む、前記
   ＲＩＳＣ−ＣＰＵを用いた組込み機器として構成された
   ことを特徴とする請求項１または２記載のデバッグモニ
   ター。