SH7216にて、IRQ0Fフラグが1ではないときに、不定期にIRQ0割り込みが呼ばれる

お世話になります。

問い合わせの現象はとしては、外部のINT信号なし、IRQ0フラグは0という状態でも
ベクタテーブルからIRQ0割り込みが不定期にコールされることです。
INT信号、IRQ0フラグの状態はオシロスコープで確認済です。

システムの仕様は、外部デバイス(バス接続)からのINT信号を/IRQ0 I/Oに入れ、
それを契機にIRQ0割り込みを発生させています。
また、他の割り込みについては、MTUのタイマ割り込みを使用しており、それ以外の割り込みは使用していません。
MTUのタイマ割り込みでIRQ0割り込みが呼ばれていないことは確認しています。

同じようは現象を経験された方、
回避方法などご教示お願い致します。

  • 外部のINT信号なし、IRQ0フラグは0という状態でも
    ベクタテーブルからIRQ0割り込みが不定期にコールされる

    //割り込み禁止
    set_fpscr(FPSCR_Init);

    でも禁止できませんか?

  • IKUZO様

    早速のご回答ありがとうございます。

    set_imask(0xF)で割り込み禁止をすると、割り込みが入らなくなることは確認できています。

    今回は、割り込みは常時受け付けたままで、現象を回避したいです。

    何かご存知でしたら、ご教授いただけますと幸いです。

  • set_imask(0xF)で割り込み禁止をすると、割り込みが入らなくなる

    割り込みの設定はレベルですか?Hiエッジ?Lowエッジ?端子状態は常時Hi?これらの設定状況と割り込みステータスフラグがクリアされているかどうかと関係します、割り込みレジスタがどうなっているのか調べます、起動時に割り込み端子が不安定で割り込みが残留しているようなことはありませんか?プログラムの中で割り込み許可フラグを有効にしている箇所があるかもしれません、全てのIRQ0の設定をコメントアウトしてみてください、IRQ0と思っていたのが実際はIRQ1だったというようなことはありませんか?

  • IKUZO様

    上記回答いたします。

     

    割り込みの設定はレベルですか?Hiエッジ?Lowエッジ?端子状態は常時Hi?

    割り込みの設定はLowエッジで、端子はHigh固定であることを確認しています。

    起動時に割り込み端子が不安定で割り込みが残留しているようなことはありませんか?

    安定動作時に、不定期にIRQ0割り込みが呼ばれています。

    プログラムの中で割り込み許可フラグを有効にしている箇所があるかもしれません、全てのIRQ0の設定をコメントアウトしてみてください、IRQ0と思っていたのが実際はIRQ1だったというようなことはありませんか?


    IRQ0に関して、割り込み許可フラグはなく、以下の設定を確認しています。

     ・PFCでIRQ0入力になっていること

     ・IRQ0の割り込み優先レベルが1であること

      IRQ0割り込みが入ると、SRレジスタのIビットが1になること

     ・IRQ1-7の割り込み優先レベルが0(不使用)であること

    よろしくお願いいたします。

  • IRQ0割り込みが入ると、SRレジスタのIビットが1になること

    ということはmain関数の最初のところではSRレジスタのIビットが0であるが

    何かの理由で割り込みが入り1になるということですね

    今開発されているSH7216ボードは手製ですか?購入品ですか?

    もし手製であるならIRQ0入力端子の半田不良ではないですか?

    可能であればSH7216も交換してやってみてはどうですか?

  • IKUZO様

    ということはmain関数の最初のところではSRレジスタのIビットが0であるが

    何かの理由で割り込みが入り1になるということですね

    はい。仰る通りです。

    今開発されているSH7216ボードは手製ですか?購入品ですか?

    手製ですが、半田不良は考えられない状況です。(実績のある基板のため)

    H/W要因ではない場合、今回投稿させて頂いたような事例のご経験はないでしょうか?

    ※よく聞く”割り込みが入らない”というQA話はありますが、不定期に割り込みが入るは聞いたことがないため。。。

  • 不定期に割り込みが入るは聞いたことがないため

    全くそのとうりです、ノンマスカブルでないのに禁止して割り込みが入るというのは史上初めてです、わたくしの経験ではハードウェアかCPUのバグ等と決めつけ、サポートに何回も苦情を言い1年ぐらい経ってソースをよく見るとプログラムの端の解りにくいところで不定期にポートをドライブしていたなんてことがありました、一度全部プロジェクトをクリアしてLEDチカぐらいにしてテストすることをお勧めします、それでもおかしいならサポートに試作ボードを送付してみてもらってください。

    追記です:コンパイラーが不正な命令を生成することがあるので最適化OFFにしてアライメントは間違えないでください

  • IKUZO様

    全くそのとうりです、ノンマスカブルでないのに禁止して割り込みが入るというのは史上初めてです、

    こちらについては前段で申し上げた通り、set_imask(0xF)で割り込み禁止にすると、割り込みは入りません。


    一度全部プロジェクトをクリアしてLEDチカぐらいにしてテストすることをお勧めします

    本調査用に、機能をシュリンク(main内ループとIRQ0用割り込み処理)したテストアプリにしていますが、そのテスト環境で本事象が発生しています。

  • そのテスト環境で本事象が発生

    ということですよね、その前に

    まず確認したいと思っているのが

    オシロスコープで確認済みとのことですが、

    まさかアナログオシロではないですよね、

    デジタルオシロで正確にトリガをかけて観測されてますよね?

    可能であれば+3.3Vに固定しましょう、デバイスを切り離し+3.3Vにする

    これができれば一つの疑問点は取り除かれます

    これをやっていただいて、次はソフトの不都合個所の切り分けです

    IRQ0用割り込み処理)したテスト

    その部分ですがモジュール単位(c++であればクラス分け)で作成されていれば

    怪しいところのモジュールをコメントアウトして

    症状が改善されるのか見たら良いです

    そもそもソースコードが短時間で検証できないほど膨大なのでしょうか?

    追記:

    外部のINT信号なし、IRQ0フラグは0という状態でも
    ベクタテーブルからIRQ0割り込みが不定期にコール

    IRQフラグは0という状態でも

    1.この意味は割り込み禁止してもという意味か?

          INTC.IPRレジスタで禁止

    2.割り込みステータスが0になっているのにコールされるのか?

         本人はベクタからコールされていると述べているが、他の個所からコールしているのでは?

  • IKUZO様

    デジタルオシロで正確にトリガをかけて観測されてますよね?

    デジタルオシロでトリガをかけて観測しています。

    その部分ですがモジュール単位(c++であればクラス分け)で作成されていれば

    怪しいところのモジュールをコメントアウトして

    症状が改善されるのか見たら良いです

    そもそもソースコードが短時間で検証できないほど膨大なのでしょうか?

    外部デバイスの特定アドレスAをリード後、特定アドレスBをライトした際に、不定期で現象が発生するというところまでは絞れています。

    外部デバイスからINT信号が入っていない、かつ、CPUのステータスとしては割り込みが発生していないのに、割り込みが発生する理由が不明です。

    IRQフラグは0という状態でも

    1.この意味は割り込み禁止してもという意味か?

          INTC.IPRレジスタで禁止

    2.割り込みステータスが0になっているのにコールされるのか?

         本人はベクタからコールされていると述べているが、他の個所からコールしているのでは?

    IRQ0フラグは、INTC.IRQRRレジスタのIRQ0Fビットのことを指しています。
    先のコメントに記載したset_imask(0xF)で割り込み禁止にして、割り込みが入らないことを確認しています。
    また、INTC.IPRレジスタの設定を0にしても確認しましたが、割り込みは入りませんでした。

  • 外部デバイスからINT信号が入っていない、かつ、CPUのステータスとしては割り込みが発生していないのに、割り込みが発生する理由が不明です。

    であれば一つ提案です

    割り込みハンドラを下記のように作成します

    void irq0_int(void)

    {

    nop();

    }

    そこで

    // *** Interrupt IRQ0
    void INT_IRQ0(void)
    {
    extern void irq0_int(void);
    irq0_int();
    /* sleep(); */
    }

    のようにベクタ処理先を書き換えて

    nopでブレークしてみてください。

    これで割り込みが入らないとしたらIRQ0以外から

    該当のIRQ0ハンドラをコールしているということです。

  • ベクタ処理先を書き換えて

    nopでブレークしてみてください。

    アドバイス頂いた調査は実施しておりまして、結果 該当のIRQ0ハンドラがコールされます。

    動きとしては正しくコールされている状態です。

    ベクターテーブル→INT_IRQ0→irq0_intです。

    繰り返しとなり恐縮ですが、IRQ0のベクタ番地のトリガである、

    IRQ0ピン(I/O)に割り込みトリガが入っていないにも関わらず、

    INT_IRQ0に飛んでくることが投稿させて頂いた件になります。

  • IRQ0ピン(I/O)に割り込みトリガが入っていないにも関わらず、

    INT_IRQ0に飛んでくることが投稿させて頂いた件になります。

    そうでしたか、難しい内容ですね

    サポートに相談されてみてはいかがでしょうか

    きっと珍しい現象ですから

    調べていただけるのではないでしょうか。

    追記:その前にCPU交換しましょう

    あるいはボード3枚ぐらい同じ現象があるのか確認してください。

  • 追記:その前にCPU交換しましょう

    あるいはボード3枚ぐらい同じ現象があるのか確認してください。

    こちらも実施しておりまして、同じ現象が出ております。

    サポートへの相談は、別途検討したいと思います。

    ありがとうございます。

  • 実績のある基板のため

    余談かもしれませんが

    CPUボード自体のノイズ耐性とか大丈夫なんでしょうか?

    CPUボードに電源を供給していた電源装置からノイズが乗っていたとか、CPUの1.8Vが1.5Vしかなかったとか基板自体はどうなのでしょうか?CPU周りのデカップリングコンデンサー等は十分ですか?

    基板製造現場で部品を間違えることは良くあることですよ。

    開発環境はまさかアセンブラではないですよね

    HEWでもコンパイラバージョンは?やCPUの選択等の設定も大丈夫ですよね。