stlと申します。
お世話になっております。 RA2E1を使用した開発中に、以下のような現象が発生しています。
RA2E1を使用したシステムで、以下のような問題が発生しています。
タイマー出力（GTIOC5AおよびGTIOC8B）を動作させている状態で、LVD（低電圧検出）の割り込みが発生すると、Default_Handler が呼び出されて例外が発生します。
Default_Handler
LVD割り込みでは特別な処理は行っておらず、フラグの設定など軽微な処理のみを行っています。
LVD関連の初期化は事前に実施しており、エラーも返ってきていません。
問題は、LVD割り込み後に続く処理が何も行われていなくても発生します。
この現象はGTIOC5Aのみが動作している場合には発生しないようです。
このことから、GTIOCの動作とLVD割り込みが何らかの形で干渉しているのではないかと考えています。
以下の点についてご教示いただけますでしょうか：
GTIOCの動作とLVD割り込みが競合・干渉する可能性はあるか？
LVD割り込み後に Default_Handler が呼ばれる原因として想定される事項は何か？
その他、設定や初期化の面で注意すべき点があれば教えていただきたい。
ご確認のほど、どうぞよろしくお願いいたします。
わわいです
> LVD割り込み後に Default_Handler が呼ばれる原因として想定される事項は何か？
そんな難しい話ではなく、たんに
Default_Handlerが割り当てられている想定外の割り込みが発生した、だけじゃないですかね。
まずはどの割り込みでそいつを呼び出したのかを特定することです
大前提として、登録されていない割り込みなどが起きた場合はDefault_Handlerが呼び出されます。
GTIOC5A/GTIOC8Bにそれぞれ割り込みとハンドラがついになっていてGTIOC5Aが動作していると起こるとなるとGTIOC5AのハンドラにCPU例外が起こってDefault_Handlerが呼ばれているのだと思います。もしくはGTIOC5Aがらみの処理に例外発生の要因が含まれている。
例外の要因として考えられるのはゼロ割とかの演算系やスタックポインタがらみです。ポインタ演算でアクセスできない場所のアクセスもありそうですね。デバッガでDefault_Handlerでブレークする設定にして、どこからジャンプしたのか確認するところから始めるのがいいと思います。
>GTIOCの動作とLVD割り込みが競合・干渉する可能性はあるか？
FSPで追加したコードをおかしな感じに変更していない場合は、ないと思います。
GTIOC8が負荷の大きな回路を駆動しており、GPT8が動いたタイミングで、VCCに電圧降下が生じてLVDが動いている事は考えられなくはないです。
VCCにオシロのプローブをつないでおき、VCC電位より200mV程度低い電圧をトリガレベルにして、fallエッジ、シングルトリガで引っかかるかどうか。ハード的に本当にVCC電位の電圧降下が生じているのかを観測するのが第一かなと思います。
>LVD割り込み後に Default_Handler が呼ばれる原因として想定される事項は何か？
一番ありがちなのは、スタックメモリが足りていないケースかと思います。
BSPタブの、Main stack sizeをとりあえず0x800などに増やしてみて、挙動が変わらないかどうか。
割り込みから呼ばれる関数内で、
int a[400];
の様なメモリの使い方（自動変数でサイズの大きな領域確保など）をしているところがないでしょうか。
>> デバッガでDefault_Handlerでブレークする設定にして、どこからジャンプしたのか確認するところから始めるのがいいと思います。
Default_Handlerでブレークする設定をしたとして、どこからジャンプしたのかということは、どのようにすれば確認出来るのでしょうか？
コール・スタック情報使う事になります。デバッグ機能についています。デバッグ情報を出力してビルドすることをお忘れなく。あとDefault_Handlerから抜けないようにwhile(1){}を仕込んでおくといいと思います。
関係ないと思われる箇所のプログラムを修正していたところ、なぜか上記の問題が発生しなくなりました。 原因ははっきり分かっていませんが、現象は再現しなくなっています。
ご回答くださった皆さま、ありがとうございました。 もし再発した場合は、改めてご相談させていただくかもしれません。
> 原因ははっきり分かっていませんが、現象は再現しなくなっています。
これはダメですよ。
再現しなくなっている、ではなくて、再現しないように見えてしまっている、です。事態はより深刻になってしまっている、と考えましょう。
きっちり原因をはっきりさせて、なぜこういうことになるか、を理解しましょう。
まあ、動作がおかしくても、まあしゃーないねー、で済むならべつにいいんでしょうけど
> Default_Handler が呼び出されて例外が発生します。Cortex-Mコアを使っていて、何の例外だか分からない時はひとまず Fault Status レジスタを確認してみると良いです。e² studioを使っているならFault Status ビューについてのe² studio ヘルプを参照してください。e2 studio ユーザーガイド > デバッグに関する機能 > ビュー > Fault Status他の開発環境でも似たような表示画面があるかと思います。おおまかに何関係の例外だかは分かるはずです。ある程度絞れたら例外ハンドラを作ってキャプチャーできるか確認するなりしてみてください。Fault Statusレジスタの意味についてはArm系マイコンのWeb記事を探してみてください(レジスタの内容はe² studioかどうかには関係ありません)。
>>例外ハンドラを作ってキャプチャーできるか確認
「例外ハンドラを作る」とはどういう意味でしょうか？ また、「キャプチャー」とは具体的にどのような処理を意味していますか？
Default_Handlerではないハンドラを参考にして、自分で書けば良いと思います。