R5F107AEで意図しないタイミングでソフトリセットが発生します。RESFレジスタによりリセット要因を調査すると、「WDT」や「パリティエラー」や「不正命令」など、色々な要因でリセットしていますが、「不正メモリアクセス」でリセットすることが多いです。・PCとUART通信を1sec毎に行っていて、リセット発生頻度は連続通電で１日に１回程度です。・リセットタイミングは、送信転送完了割り込み処理を終了し次の１バイトを送信時にリセットしています。・CS+のスタックメモリ見積ツールを使用し、スタック領域破壊は無いことを確認しました。・リンクディレクティブファイルに問題ないことはメーカーに確認しました。・今のところE2Liteを接続してのオンチップデバッグではリセットしていません。・EEPROMエミュレーション・ライブラリPack01 パッケージVer2.1.0を使用しています。
コードとコード生成ツールを確認した限りでは変な割り込みはなさそうですが（再度調査します）何かマイコンリセットしてしまう要因は何か考えられますでしょうか。アドバイスいただけたらと思います。
現象からすると、受信バッファの定義範囲を超えるサイズを受信するなどにより、その後ろに定義した変数の値を壊すことが考えられます。
例えば、以下のように宣言しているとして、単純にrxbufに受信データを順次格納するとします。
unsigned char rxbuf[256];
unsigned char rxstatus;
256バイト以上受信してしまうと、受信データを保存する領域が、rxstatusの変数領域にはみ出してしまうなどのケースがあり得ます。上記の場合は、rxstatsuが破壊されることになりますので、それ以降プログラムがどのように動作するかは保証できなくなります。※リングバッファ構造や、キュー構造なら別ですが。
リセットがかかる原因は、スタック破壊以外にもこのような配列のサイズを超えてアクセスすることや、ポインタの操作誤りなどによるものがほとんどです。
早速のご回答ありがとうございます！
バッファサイズは疑っていたので、バッファサイズ自体は十分にサイズを確保していて受送信の度にクリアしているため問題ないと考えています。
ポインタ関連は見直してみます。
リセットタイミングがデータ送信途中のため（受信は禁止しています）送信バッファや送信処理周りでポインタを使用しているところが怪しいと考えて良さそうでしょうか。
また、後出しで申し訳ありませんが、元々R5F100AEで正常に動作しているコードをR5F107AEに移植したものになっています。
R5F100AEではリセットは発生していません（頻度が低いため見れていないだけかもしれませんが）
R5F107AEのFEF00H-FF309Hは使用禁止とのことなので使用しないようにはしております。
R5F107AEにすることによりリセットがかかりやすくなる要因は考えられますか？
流し読みしてしまい送信ってことを見逃していました。失礼しました。
既に正常に動作しているコードを移植した、かつ送信となると、ちょっと通信での発生というのは考えづらいですかね。たまたま条件が重なった可能性もあるのではないかと思います。
となると、他に原因がある可能性が高いのではないかと思われます。
スタック見積はスタックオーバーフローだけを見るもので、動的なスタック破壊は把握できないです。関数内で動的なポインタ操作誤りなどによるスタック破壊もあり得ます。
おそらくポインタ操作誤りなどによる、ヒープ、スタック破壊くらいしか考えられないですが、このような場合の調査方法はモジュールをひとつずつ無効にしながら原因個所を絞っていく方法があります。（消去法ですね）
逆にプログラムの骨組みだけ残し、ひとつづずモジュールを有効にしていく方法もあります。
1つ気になるのが、パリティエラーがなぜ要因としてあるのかが疑問ですね。
たいていリセットがかかるまでは、原因個所から数命令進んでからというのは多いと思います。なので要因がバラバラなのは理解できます。そのうち手掛かりになるものもあったりしますが、パリティエラーは受信時以外は発生しないと思いますので、想定外ですね。
もしかして、受信を無効にしているのにパリティエラーが発生しているのは、無効にしているつもりが、実は有効になっていて何かしら受信をしている可能性があるのではないかと思いました。
受信を無効にしているつもりなので、受信バッファも設定していない。でも受信割り込みが発生して受信割り込みハンドラーが動作している？となると不正アドレスにアクセスしている可能性があるのではと思いました。
わわいです。
現象を見るかぎり、あなたのコードで不正アクセスが起こっていて、それがエラーの原因になってるようです
C言語上では、実行時のエラーチェックは行われないため、不正アクセス時にはエラーは出ません。
どこでエラーが出てくるか、というと、不正アクセスによって発生したメモリ不整合がその後のコード実行により破綻していき、やがて実行出来なくなったらそれがエラーとして表に出てくるようになります
ってことで、発生したエラーはたいてい不正アクセスの原因とは全く関係ないですし、エラー発生時の状況は全く参考とはなりません。
んじゃどうすればいいのか、というと、がんばってコードとにらめっこしてバグを見つける、か、デバッグ機能を駆使して、どこでおかしなアクセスをしているかってのを見つける、しかないと思われます。
＃も一つ面倒なのが、不正アクセスをしててもエラーとして表に出てこないことだったり。
がんばってください。
ポインタ操作と受信設定もが怪しそうですね。ありがとうございます。
ありがとうございます！エラー発生時の状況は参考にならないんですね(><)
”送信タイミング”にこだわらず確認しようと思います。
-donkey-様 わわい様
アドバイスありがとうございます。
地道にコード確認して箇所を絞っていこうと思います。
（もし他にも何か思いつきましたらご教授いただけると幸いです）
進展有りましたらまたご連絡いたします。
最適化オプションを有効にしてたら無効(-O0)にしてみても同じ結果かを見ると良いかもです。あと、通信バッファはstatic修飾していますよね？
お返事遅くなりましてすみません。最適化オプションはコンパイルオプションの最適化であっていますか？有効にしていたので、無効にして違いを見てみます。
通信バッファは最終というか大元はstatic修飾していますが、途中ポインタで渡していたりするのでポインタ操作も怪しそうなので順に追いながら確認してみます。
ありがとうございます。