Nios® II SBT for Eclipse におけるレジスターセットから例外要因を確認する方法

1. はじめに

このコンテンツでは、Nios^® II SBT のデバッグ機能を使用して、発生した例外の要因を Nios^® II レジスターセットから特定する方法についてご紹介します。

レジスター確認用の例外ハンドラーを使用した例外要因の特定方法に関しては、下記記事で紹介しています。デバッグ用にソフトウェアを修正する必要がありますが、例外発生時にデバッガーが外れてしまったり、例外発生直後を Break Point で止められない場合などに有効な手段となります。

参考： Nios^® II SBT for Eclipse における例外発生要因の確認方法

このコンテンツでご紹介する方法では、ソフトウェアを変更せずデバッグ画面に表示される Nios^® II レジスターセットから例外要因を特定します。

Nios^® II のレジスターセットについては、下記資料に詳細が記載されています。

参考： Nios^® II Processor Reference Guide - 3.4. Registers

注記：
このコンテンツで紹介するレジスターの確認方法は、Nios^® II/f のみに対応しています。

2. Nios^® II レジスターセット

この章では Nios^® II プロセッサーに実装されている、レジスターセットについて解説します。

Nios^® II には、

General-Purpose Register
Control Register

が実装されており、本コンテンツではデバッグに使用する、

General-Purpose Register "ea"
Control Register "exception"

について説明します。

2-1. General-Purpose Register "ea"

Nios^® II プロセッサーには 32 個の 32 bit General-Purpose Register が実装されています。
一部のレジスターはアセンブラにて認識可能な名前が用意されており、【図1】の通り r0, r1, r24 ～ r31 の Name 欄は、レジスター名として Nios^® II SBT の Debug Window で表示されます。

【図1】 Nios^® II General-Purpose Register 一覧

例外発生時のデバッグに使用する General-Purpose Register は、
Register : r29, Name : ea（以下 ea register）です。

ea register は【図2】にも記載されている通り、例外戻りアドレスを格納するレジスターです。
ea register を参照することにより、【図2】に記載の例外が起こった際、どのアドレスを最後に例外が発生したかを確認することができます。

ea register により戻りアドレスを確認できる例外は、【図2】の Adress 欄 "ea-4" が記載されている例外が対象となります。

【図2】 Nios^® II 例外一覧

2-2. Contorol Register "exception"

Nios^® II プロセッサーには 32 個の 32 bit Control Register が実装されています。 Control Register は、現在の Status の読み込み、プロセッサーの動作の制御を行えます。

Nios^® II の Control Register は【図3】の Name 欄から確認できる通り、それぞれアセンブラで認識可能な名前を有しており、General-Purpose Register 同様にデバッグウィンドウで認識することができます。

【図3】 Control Register 一覧

例外発生時のデバッグに使用するレジスターは、
Register : 7, Name : exception（以下、exeception register）です。

exception register では、【図4】の Bit field の Cause field を参照することにより、どの例外が発生したのかを確認することができます。

【図4】 exception register の Bit field と概要

Cause field に記載される値は、【図4】の Cause Code 欄に定義されており、この値が exception register の 2 ～ 6 bit 目（Cause field）に格納されることにより、どの例外が発生したのかを確認することができます。

3. Nios^® II SBT での確認方法

では、実際にデザインサンプルを動作させ、例外発生時のデバッグを試してみます。

3-1. 使用デザインサンプル

以下の『参考』に記載のリンクは、今回使用する PIO Core のデザインサンプルとなります。
このコンテンツでは異常例外の検証ではなく、割り込み（例外の一種）の検証になっていますので、例として割り込みのサンプルを使用して例外要因の確認方法を解説します。
異常例外も同様の方法で確認可能となっています。

参考： Embedded Peripherals IP - PIO Core サンプル

3-2. Debug perspective

今回のデバッグ手法では Nios^® II SBT の Debug perspective を使用して、デバッグを進めていきます。Debug perspective 起動時の表示例を【図5】に示します。

【図5】 Debug perspective の表示例

Debug perspective の各 Window について以下に説明します。

Debug Window
現在動作中の関数がハイライトされます。関数名の右側に最終実行時のアドレス、左側に関数の実行順番が記載されます。
View Window
Register ／ Memory ／ Variables などをソースの進行に合わせて確認できます。2-1, General-Purpose Register "ea"、2-2, Control Register "exception" にて紹介した、各レジスターの名前がリストされているのが確認できます。

【図6】 Resister Tab の表示例
Source Window
進行中のソースの現在位置を表示します。行数の左側をダブルクリックすると、ブレイクポイントを設定することができます。XIP 実行でのブレイクポイントの設定方法は、以下のコンテンツをご参照ください。
参考： Nios^® II SBT for Eclipse における Run/Debug Configuration 設定の使い方 - 5. XIP 構成におけるデバッグの方法
Console Window
JTAG 使用時の Console への表示などを行います。このコンテンツでは Console Window にDisassembly タブを追加してデバッグします。
追加方法は、Nios^® II SBT Window メニュー ⇒ Show View ⇒ Other にて Show View Window が開くので、Debug フォルダ内の Disassembly を選択します。
他の Window についても、Show View より追加可能です。

【図7】 Show View Window

3-3. デバッグ手順

今回確認するのは ” ea "、" exception " レジスターの値です（"pc" は現在位置確認のため参照しています）。
実際に例外を発生をさせた際の各 Window の状態について解説します。
今回は PIO サンプル内の割り込みハンドラーに Break point を設定し動作させています。

【図8】例外発生時の ea register の確認

【図8】は、ea register について解説するためにピックアップしています。
【図8】の通り、ea register に例外戻りアドレスが格納され、main の現在のアドレスが ”ea-4” のアドレスなっていることがわかります。

また【図9】を確認すると、exception register には、今回プッシュボタンにより割り込みを入れたので、Cause Field に "2” が入力され ”Hardware interrupt” であることがわかります。

【図9】例外発生時の exception register の確認

最後に【図10】により ”pc" レジスターについて解説します。

【図10】例外発生時の "pc" レジスターの確認

"pc" レジスターには、次に実行する命令のアドレスが格納されます。
Disassembly Tab を参照すると、逆アセンブルされた命令を確認することができ、これらの命令はアドレスと一対一に紐づいているため、"pc" レジスターのアドレスを確認することにより、次に実行する命令を確認することができます。

4. まとめ

以上が例外の要因を Nios^® II レジスターセットから特定する方法です。
これらのレジスターを参照することにより、新たにソフトウェアを用意することなく、例外発生時のデバッグが可能となります。

1. はじめに

2. Nios® II レジスターセット