JP2809174B2 - デバッグ装置 - Google Patents

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明はデバッグ装置に関
し、特にトレースメモリを用いた組み込みシステム用の
デバッグ装置に関する。

【０００２】

【従来の技術】近年、マイクロプロセッサやマイクロコ
ントローラなどの性能向上にともなって、従来複数のマ
イクロプロセッサを使用していた処理が単一のマイクロ
プロセッサだけで対応できるようになりつつある。

【０００３】このような状況で有効なソフトウェアにリ
アルタイムＯＳがある。複数の処理に対応する複数のア
プリケーションを、個々のアプリケーションの独立性を
保ったまま稼働させるために使用する。そのようなリア
ルタイムＯＳの一例としてここではＩＴＲＯＮ ＯＳを
取り上げて説明する。

【０００４】ＩＴＲＯＮでは、タスクを表１に示す７つ
の状態のうちのどれかになるように管理する。

【０００５】

【表１】

【０００６】また、表１の各状態がどのように変化する
かを示す状態遷移図を図３に示す。組み込みシステムに
ＯＳを使用して稼働させる場合、ＯＳが管理するさまざ
まな資源（タスク，フラグ，セマフォ，メールボック
ス，メモリプール，メモリブロック）などは、ＯＳによ
って様々な状態の間を遷移させられ、かつ、必ずＯＳに
よって一貫性を保たれながら状態遷移をする。

【０００７】一例として、ＩＴＲＯＮ準拠のＯＳである
ＲＸ１１６におけるＯＳ資源データの管理状態を示す概
念図である図４を参照して、このＯＳ資源データがどの
ように管理されているかを説明すると、この図ではタス
ク１０１〜１２４とを示し、これらタスク１０１〜１２
４は、ＲＵＮ，ＲＥＡＤ，ＳＬＥＥＰ（ＷＡＩＴに含ま
れる），ＳＵＳＰＥＮＤ，ＷＡＩＴ−ＳＵＳＰＥＮＤな
どの内のいずれかの状態になっており、状態遷移途中の
状態で存在してはならない。

【０００８】また、これらタスク１０１〜１２４は、上
記各状態対応のタスク登録（レディ）キュー１０００
と、フラグ登録キュー１００１（フラグ２００１，２０
０２を含む）と、セマフォ登録キュー１００２（セマフ
ォ２００３，２００４を含む）と、メールボックス登録
キュー１００３（メールボックス（メッセージ）２００
５，２００６を含む）と、メモリプール登録キュー１０
０４（メモリプール（メモリブロック）２００７，２０
０８を含む）と、タイマキュー１００５とのいずれかに
接続されている。

【０００９】ここで、レディキュー１０００に接続され
たタスク１０１はＲＵＮ状態のタスクであり、タスク１
０２はレディキュー１０００のプライオリティ１に接続
されたタスク（ＲＥＡＤＹ状態) のタスクであり、以下
タスク１０３，１０４，１０５はそれぞれレディキュー
１０００のプライオリティ２，３，３に接続されたＲＥ
ＡＤＹ状態のタスクである。また、タスク１０６，１０
７，１０８，１０９，１１０，１１１はそれぞれフラグ
２００１，セマフォ２００３，メッセージ２００５，メ
モリブロック２００７，メッセージ２００５，メモリブ
ロック２００７の各キューに接続されＷＡＩＴ（待ち）
状態である。

【００１０】また、タスク１１２は登録キューのみに接
続されＤＯＲＭＡＮＴ状態である。同様にタスク１１
３，１１４，１１５，１１６，１１７はそれぞれメッセ
ージ待ち，セマフォ待ち，タイマ待ち，セマフォ待ち，
メッセージの各キューに接続されＷＡＩＴ状態である。

【００１１】タスク１１８は登録キューのみに接続され
ＳＵＳＰＥＮＤ状態であり、タスク１１９，１２０，１
２１はそれぞれセマフォ，タイマの各キューに接続さ
れ、タスク１２２はスリープしておりいずれもＷＡＩＴ
状態である。

【００１２】タスク１２３はタイマキューに接続されＷ
ＡＩＴ−ＳＵＳＰＥＮＤ状態である。タスク１２４はス
リープしておりＷＡＩＴ−ＳＵＳＰＥＮＤ状態である。

【００１３】タスク１１５，１２０の後にタスク１２２
を周期的に起床するためのタイマ管理ブロック２０１，
２０２を接続してある。また、メールボックス２００６
にはメッセージ３０１，３０２を示す。

【００１４】このように、ＲＵＮあるいはＲＥＡＤＹ状
態のタスク例えばタスク１０１はタスク登録（レディ）
キュー１０００に接続されていなければならず、ＳＬＥ
ＥＰ状態のタスク例えばタスク１１５はタイマキュー１
００５に接続されていなければならない。さらにフラグ
待ち状態のタスク１０６ならフラグ（待ちキュー）２０
０１あるいは２００２に接続されていなければならな
い。リアルタイムＯＳは、タイムアウト処理を実現する
ために一定周期で起動されるクロックハンドラを持って
いる。このクロックハンドラは、時間待ち状態のタスク
がタイムアップしたかどうかを判定し、タイムアップし
ている場合には時間待ちキューから外し、ＳＵＳＰＥＮ
Ｄ状態でなければレディキュー１０００に接続する。こ
のようにリアルタイムＯＳはＯＳ資源データを操作す
る。上述の一貫性はシステム稼働中常に維持されていな
ければならない。

【００１５】しかしながら、リアルタイムＯＳの開発途
中においては、あってはならない状況も発生し得る。

【００１６】例えば、一定時間経過後に起床すべきタス
クが起床してこない事例を考える。リアルタイムＯＳの
開発途上においては、タスクが実行可能状態であるにも
かかわらずタイマキューに接続されたままという事態や
どのキューにも接続されていないという事態が発生し得
る。

【００１７】このような事態が発生した場合、タイマハ
ンドラや割り込み中から発行可能なシステムコールのコ
ードの見直し作業のみならず、クロックハンドラや個々
のシステムコール全般においても行なわねばならない。
何故ならば、割り込みおよび状態によって実行されるプ
ログラムの順序が時々刻々と動的に変化するからであ
る。プログラムの様々な箇所で別のプログラムに制御が
移される可能性を持っている。

【００１８】特開平１−１０６１４３号公報（文献１）
記載の従来のデバッグ装置は、プログラムの実行履歴を
格納するトレースメモリ１と、トレースメモリ１が一杯
になったことを検出するフルデテクタ２と、タスク実行
時に発生したイベントを検出するイベント検出手段３
と、検出したイベントに応答してトレースメモリ１への
履歴書き込みの停止/ 継続を制御するトレースメモリ制
御手段５とを備える。

【００１９】次に、図５を参照して、従来のデバッグ装
置の動作について説明すると、この従来のデバッグ装置
は、トレースメモリ１を複数のバンクに分割し、それぞ
れのメモリバンクをイベント検出手段３でイベント条件
と関連付けることによって、イベント毎のトレース結果
を効率的に残すことが可能であり、これにより、トレー
ス情報を印刷したり、写真撮影する手間を省くことが可
能であると主張している。

【００２０】しかし、この従来のデバッグ装置では、障
害箇所が特定化できているという前提条件が存在して始
めて機能する。障害箇所が特定できない場合には、トレ
ースメモリバンクとイベント条件を関連付けることがで
きず、結果として、所望の効果を得ることができない。

【００２１】

【発明が解決しようとする課題】上述した従来のデバッ
グ装置は、リアルタイムシステムにおけるデータが時々
刻々と書き換えられている上にトレースメモリの容量は
有限であるので、トレースメモリにすべてのアクセス履
歴を残すことは不可能であるため、どのプログラムアド
レスでどのデータに対してどのような操作をしたかを知
ることは大変困難であるという欠点があった。

【００２２】さらに、割り込みによって、実行プログラ
ムの順序が動的に変化する結果、不具合原因は全プログ
ラム領域に存在し得るため、不具合箇所の特定が大変困
難であるという欠点があった。

【００２３】

【課題を解決するための手段】本発明の第１のデバッグ
装置は、プログラムの実行履歴であるトレース情報を格
納するトレース記憶手段と、前記トレース記憶手段が満
杯状態となったことを検出し満杯情報を出力する満杯検
出手段と、前記満杯情報および前記プログラムの実行時
に発生したイベントを検出しイベント検出情報を出力す
るイベント検出手段と、前記イベント検出情報に応答し
て前記トレース記憶手段への前記トレース情報の書き込
みの停止/ 継続を制御するトレース記憶制御手段とを備
え、前記プログラムの複数の処理に対応する複数のアプ
リケーションの各々の独立性を保持しながら管理対象の
複数の資源を予め定めた複数の状態間を遷移させこの状
態の一貫性を維持させるよう制御するリアルタイムオペ
レーションシステムで稼働される組込みシステムをデバ
ッグするデバッグ装置において、起動制御命令の供給に
応答して起動され前記一貫性をチエックし一貫性チエッ
ク結果をイベント検出手段に通知する一貫性チェックプ
ログラムを備え、前記イベント検出手段が、前記起動制
御命令を出力し前記一貫性チエック結果に応答して前記
トレース情報の書き込みの停止/ 継続を制御することを
特徴とするものである。

【００２４】本発明の第２のデバッグ装置は、プログラ
ムの実行履歴であるトレース情報を格納するトレース記
憶手段と、一定周期で起動されこの一定周期のクロック
を供給するクロックハンドラ処理手段と、前記プログラ
ムの実行時に発生したイベントを検出しイベント検出情
報を出力するイベント検出手段と、前記イベント検出情
報に応答して前記トレース記憶手段への前記トレース情
報の書き込みの停止/継続を制御するトレース記憶制御
手段とを備え、前記プログラムの複数の処理に対応する
複数のアプリケーションの各々の独立性を保持しながら
管理対象の複数の資源を予め定めた複数の状態間を遷移
させこの状態の一貫性を維持させるよう制御するリアル
タイムオペレーションシステムで稼働される組込みシス
テムをデバッグするデバッグ装置において、前記一定周
期が、前記トレース記憶手段の前記トレース情報の一巡
期間よりも短かく設定され、前記クロックに同期して起
動され前記一貫性をチエックし一貫性チエック結果をイ
ベント検出手段に通知する一貫性チェックプログラムを
備え、前記イベント検出手段が、前記起動制御命令を出
力し前記一貫性チエック結果に応答して前記トレース情
報の書き込みの停止/ 継続を制御することを特徴とする
ものである。

【００２５】

【発明の実施の形態】次に、本発明の第１の実施の形態
を図５と共通の構成要素は共通の文字を付して同様にブ
ロックで示す図１を参照すると、この図に示す本実施の
形態のデバッグ装置は、従来と共通のトレースメモリ１
と、フルデテクタ２と、トレースメモリ制御手段５とに
加えて、イベント検出手段３の代りにイベント検出手段
３Ａと、イベント検出手段３Ａによって起動されリアル
タイムＯＳが維持すべき一貫性をチェックしチエック結
果をイベント検出手段に通知するチェックプログラム４
とを備える。

【００２６】次に、図１を参照して本実施の形態の動作
について説明すると、従来と同様に図４に示すＲＸ１１
６のＯＳ資源データの管理システムを対象とする。

【００２７】ここでは、タスク１０１，タスク１０２，
タスク１０３，タスク１０４，タスク１０５に関して説
明し、それぞれが一定周期で「起床」と「待ち」を繰り
返しているとする。すなわち、タスク登録（レディ）キ
ュー１０００とタイマキュー１００５との間の往復を反
復しているとする。

【００２８】上記システムにおいてタスク１０１が起床
しなくなる事例を考える。この事例の要因である不具合
が、アプリケーションプログラム側あるいはリアルタイ
ムＯＳのいずれの方にも存在する場合があり得る。ここ
では、特に、リアルタイムＯＳの開発途中を想定し、し
たがって、リアルタイムＯＳに不具合が存在する場合を
考える。従来の技術で説明したように、リアルタイムＯ
Ｓは、ＯＳ資源データの一貫性を維持しながらシステム
を稼働させなければならない。

【００２９】一般に、リアルタイムシステムにおいて発
生する不具合の原因は全プログラム領域に存在し得る。
割り込みハンドラから呼び出されるシステムコールに不
具合がある場場合やクロックハンドラに不具合がある場
合、あるいは個々のシステムコールに起因する場合など
多岐にわたる。

【００３０】まず、従来と同様に、トレースメモリ１は
プログラムの実行毎にその実行履歴を格納する。トレー
スメモリ１が一杯になった時点で、フルデテクタ２はそ
の状態を検出し、イベント検出手段３Ａにその旨を通知
する。この通知に応答してイベント検出手段３は、チェ
ックプログラム４を起動する。このチェックプログラム
４はリアルタイムＯＳが維持すべき一貫性をチェックす
るように使用者によって用意される。

【００３１】一貫性のチェックについては上述の従来の
技術で説明したが、ここで、さらに詳細に説明すると、
ＲＵＮあるいはＲＥＡＤＹ状態のタスク、例えばタスク
１０１はのレディキュー１０００に接続されていなけれ
ばならない。さらに、レディキュー１０００に接続され
ているものはタスクの状態がＲＥＡＤＹでなければなら
ない。また、ＳＬＥＥＰ状態のタスク、例えばタスク１
１５はタイマキュー１００５に接続されていなければな
らず、タイマキュー１００５に接続されているタスクは
ＳＬＥＥＰ状態でなければならない。また、フラグ待ち
状態のタスク１０６ならフラグ（待ちキュー）２００１
あるいは２００２のいずれかに接続されていなければな
らず、フラグ２００１あるいは２００２に接続されてい
るタスクはフラグ待ち状態でなければならない。さら
に、繰り返し述べることになるが、上記の一貫性はシス
テム稼働中常に維持されていなければならない。以上で
詳細に説明したようなチェックを、上記起床不能の問題
のあるタスク１０１に関し、チェックプログラム２を用
いて実施する。チェックプログラム２を実行することに
よりこのタスクタスク１０１に関して、不整合状態にな
っているかどうかを検出できる。例えば、レディ状態な
のにタイマキュー１００５に存在していたり、どのキュ
ーにも存在していないという状態になっている場合にそ
れを検出できる。ここで、レディ状態であるかどうかは
タスク１０１を管理する内部変数を調べることでチェッ
ク可能である。また、どのキューに属しているかはタス
ク１０１のキューのリンク先をたどることで可能であ
る。

【００３２】チェックプログラム２の一貫性チエックの
結果、トレースメモリ１を停止する必要がある場合はそ
の旨をイベント検出手段３Ａに通知する。イベント検出
手段３Ａは、必要に応じてトレースメモリ制御手段５に
トレースを停止する旨を通知する。

【００３３】これにより、不具合箇所がトレースメモリ
１に残った状態でこのトレースメモリ１への書き込みを
停止することができる。したがって、明らかに不具合箇
所を容易に特定できる。

【００３４】次に、本発明の第２の実施の形態を図１と
共通の構成要素は共通の文字を付して同様にブロックで
示す図２を参照すると、この図に示す本実施の形態のデ
バッグ装置の上述の第１の実施の形態との相違点は、ト
レースメモリ１が一杯になったことを検出するフルデテ
クターを持たず、その代りに一定周期で実行されるクロ
ックハンドラ入口処理であるクロックハンドラ６と、チ
エックブログラム４の代りのチエックプログラム４Ａ
と、イベント検出手段３Ｂと、クロックハンドラ本来の
処理であるクロック処理７と、クロックハンドラ出口処
理であるレット８とを備えることである。

【００３５】ここでも第１の実施例と同一の状況、すな
わち、図４に示すＲＸ１１６のＯＳ資源データの管理シ
ステムを対象とし、タスク１０１，タスク１０２，タス
ク１０３，タスク１０４，タスク１０５のそれぞれが一
定周期で「起床」と「待ち」を反復、すなわち、タスク
登録キュー１０００とタイマキュー１００５との間の往
復を反復しているとする。

【００３６】同様に、タスク１０１が起床しなくなり、
さらに、原因としてリアルタイムＯＳに不具合が存在す
る場合を考える。

【００３７】図２を参照して本実施の形態の動作につい
て説明すると、まず、クロックハンドラ６の起動周期
を、トレースメモリ１が一巡するよりも短い周期に設定
しておく。クロックハンドラ６は一定周期で起動されて
いるために、チェックプログラム４Ａも一定周期で定常
的に起動される。第１の実施の形態と同様にチエックプ
ログラム４ＡでリアルタイムＯＳの維持すべき一貫性を
チェックする。上述のように、リアルタイムＯＳを使用
するリアルタイムシステムがクロックハンドラを保持し
ているということを利用することによって、トレースメ
モリ１が一杯になる前に周期的にチェックプログラムを
起動できる。

【００３８】一貫性チェックに関しては、従来および第
１の実施の形態で詳細に説明したためここでは省略す
る。

【００３９】チェックプログラム４Ａの一貫性チエック
結果、トレースメモリ１を停止する必要がある場合はそ
の旨をイベント検出手段３Ｂに通知する。イベント検出
手段３Ｂは、必要に応じてトレースメモリ制御手段５に
トレースを停止する旨を通知する。

【００４０】これにより、第１の実施の形態と同様に、
不具合箇所がトレースメモリ１に残った状態で書き込み
を停止できるので、上記不具合箇所を容易に特定でき
る。

【００４１】

【発明の効果】以上説明したように、本発明のデバッグ
装置は、ＯＳの維持すべき一貫性をチエックし一貫性チ
エック結果をイベント検出手段に通知する一貫性チェッ
クプログラムを備え、イベント検出手段が、上記一貫性
チエック結果に応答してトレース情報の書き込みの停止
/ 継続を制御することにより、不具合の発生したプログ
ラムアドレスおよび不具合発生時にどのようなデータを
操作していたかを知ることができるため、上記不具合箇
所を容易に発見できるという効果がある。

【００４２】また、時々刻々とデータが書き換えられ、
プログラムの順序が動的に変化するリアルタイムシステ
ムにおけるプログラムの不具合を非常に効果的に発見で
きるデバッグ方法を提供できるという効果があある。

【図面の簡単な説明】

【図１】本発明のデバッグ装置の第１の実施の形態を示
すブロック図である。

【図２】本発明のデバッグ装置の第２の実施の形態を示
すブロック図である。

【図３】リアルタイムＯＳの一例におけるタスクの状態
の変化を示す状態遷移図である。

【図４】リアルタイムシステムの一例におけるＯＳ資源
データの管理状態を示す概念図である。

【図５】従来のデバッグ装置の一例を示すブロック図で
ある。

【符号の説明】

１ トレースメモリ ２ フルデテクタ ３，３Ａ，３Ｂ イベント検出手段 ４，４Ａ チエックプログラム ５ トレースメモリ制御手段 ６ クロックハンドラ入口処理 ７ クロック処理 ８ レット処理 １０１〜１２４ タスク １０００ タスク登録（レディ）キュー １００１ フラグ登録キュー １００２ セマフォ登録キュー １００３ メールボックス登録キュー １００４ メモリプール登録キュー １００５ タイマキュー ２００１，２００２ フラグ

Claims (2)

(57)【特許請求の範囲】
1. 【請求項１】 プログラムの実行履歴であるトレース情
   報を格納するトレース記憶手段と、前記トレース記憶手
   段が満杯状態となったことを検出し満杯情報を出力する
   満杯検出手段と、前記満杯情報および前記プログラムの
   実行時に発生したイベントを検出しイベント検出情報を
   出力するイベント検出手段と、前記イベント検出情報に
   応答して前記トレース記憶手段への前記トレース情報の
   書き込みの停止/ 継続を制御するトレース記憶制御手段
   とを備え、前記プログラムの複数の処理に対応する複数
   のアプリケーションの各々の独立性を保持しながら管理
   対象の複数の資源を予め定めた複数の状態間を遷移させ
   この状態の一貫性を維持させるよう制御するリアルタイ
   ムオペレーションシステムで稼働される組込みシステム
   をデバッグするデバッグ装置において、 起動制御命令の供給に応答して起動され前記一貫性をチ
   エックし一貫性チエック結果をイベント検出手段に通知
   する一貫性チェックプログラムを備え、 前記イベント検出手段が、前記起動制御命令を出力し前
   記一貫性チエック結果に応答して前記トレース情報の書
   き込みの停止/ 継続を制御することを特徴とするデバッ
   グ装置。
2. 【請求項２】 プログラムの実行履歴であるトレース情
   報を格納するトレース記憶手段と、一定周期で起動され
   この一定周期のクロックを供給するクロックハンドラ処
   理手段と、前記プログラムの実行時に発生したイベント
   を検出しイベント検出情報を出力するイベント検出手段
   と、前記イベント検出情報に応答して前記トレース記憶
   手段への前記トレース情報の書き込みの停止/ 継続を制
   御するトレース記憶制御手段とを備え、前記プログラム
   の複数の処理に対応する複数のアプリケーションの各々
   の独立性を保持しながら管理対象の複数の資源を予め定
   めた複数の状態間を遷移させこの状態の一貫性を維持さ
   せるよう制御するリアルタイムオペレーションシステム
   で稼働される組込みシステムをデバッグするデバッグ装
   置において、 前記一定周期が、前記トレース記憶手段の前記トレース
   情報の一巡期間よりも短かく設定され、 前記クロックに同期して起動され前記一貫性をチエック
   し一貫性チエック結果をイベント検出手段に通知する一
   貫性チェックプログラムを備え、 前記イベント検出手段が、前記起動制御命令を出力し前
   記一貫性チエック結果に応答して前記トレース情報の書
   き込みの停止/ 継続を制御することを特徴とするデバッ
   グ装置。