質問失礼致します。
RX63N176pinを使用したマイコンプログラムにつきまして、
発生頻度は稀（1/1000回程度）ですが、起動直後にプログラム停止してしまう事象が発生しています。
発生頻度が低く、プログラム停止する詳細箇所については把握できていませんが、
異常時の製品挙動より、電源投入→レジスタ初期化→ 割込み許可→SCI及びTPUが動作した後でメイン処理へ移行した直後、
もしくはメイン処理移行前のどこかで停止しているものと推測しています。
また、基板上には外付けのWD機能付きリセットICが実装されており、
プログラム停止時はマイコンに対しHWリセットを掛ける仕組みとなっておりますが、
HWリセットが掛かっても症状はすぐには改善されず、
プログラム停止→HWリセット→起動→プログラム停止→HWリセット→起動→・・・を繰り返し、数分経つと何事もなかったかのように復帰します。
毎回同じ箇所でシーケンスが止まっている事から、ソフトウェア起因の可能性が高いと思われるのですが、
発生頻度が稀であることからハードウェア起因も疑っております。
推察される原因等ございましたらご教示頂きたく存じます。
sktytrさん、こんにちは。NoMaYです。こういうことですよね。・ E1でデバッグすることが出来ない(なぜなら電源投入時に発生する現象だから(現状は1/1000回の頻度で発生))・ E1でデバッグ出来ないので、どこでプログラム停止(というか何らかの無限ループ？)しているか分からない・ でも、恐らく、メイン処理へ移行した直後、もしくはメイン処理移行前のどこか、であることは突き止めた・ もう少し正確には、電源投入→レジスタ初期化→ 割込み許可→SCI及びTPUが動作した後で メイン処理へ移行した直後、 もしくはメイン処理移行前のどこか・ そういう状況ではあるが、TPU割り込みは実行されず、CMT割り込みは実行されている、ことも突き止めたリカルドさんのアドバイスに対する確認は未了([追記]未了ではなくて、確認した結果、TPUとCMTの件が分かった？)＞ 予定外の割り込みが入って、予定外のアドレスに飛んでいるのかも知れない。＞ 割り込みを不許可にしてみたらどうですか。私ですと、リカルドさんのアドバイスを以下のように確認するかと思うのです。・ ポートを1つ確保してLEDを繋いで、メイン処理の先頭に来たら点灯するような処理を入れる・ あるいは、メイン処理のループの先頭でLEDトグルさせて、50%の明るさで点灯するか？(オシロによる確認が確実)・ SCI割り込み(送信/受信/エラー等すべて)が発生しないようにして、LEDは点灯するか？・ CMT割り込みも発生しないようにして、LEDは点灯するか？・ TPU割り込みも発生しないようにして、LEDは点灯するか？・ すべての割り込みに関して割り込み許可レジスタ(ICUのIENレジスタ)で割り込み禁止にして、LEDは点灯するか？また、追加の確認として、以下がどうなるか確認するかと思うのです。・ TPU割り込みとCMT割り込みの優先順位の値は何になっているか？異なるのであれば優先順位の値を逆にするとどうなるか？予期しない不安定な割り込みというと、一般論的に以下の事例はあるかな、と思いました。・ 端子割り込み入力がオープン(相手側未起動(or起動遅れ)/接触不良/断線)になっていて、想定外のタイミングで割り込み発生して、プログラム処理が破綻・ UART入力がオープン(相手側未起動(or起動遅れ)/接触不良/断線)になっていて、受信エラー割り込みに飛んでしまって、エラー割り込みルーチン内で無限ループとか、思い浮かびました。こういうのは、以下のようにちょっと境界が曖昧ですかね、、、・ 何でボード上にプルアップ抵抗が無いの？ --> ハードの問題？・ 何で内蔵プルアップ抵抗を有効にしていないの？ --> ソフトの問題？
> コメントアウトで消す方法も有ります。 > Ｃ言語なら普通のコメントは // で書きます。 > 大量にコメントアウトする所は、 /* と /**/ で挟みます。 > 戻したいときは初めの /* を消すか /**/ にします。
↑の方法では既に /* */ 形式のコメントを含むソースには適用し辛いので
#define TemporaryDisableSW1 1
とかを定義し、無効化したい場所を
#if !TemporaryDisableSW1
と
#endif // !TemporaryDisableSW1
で括る方法をお勧めします。
ひとつのスイッチで複数個所の無効化/有効化を切り替えたりスイッチを複数種類用意して無効化/有効化の条件を変えたりできるのでテスト的にあれこれ試すには便利な方法です。