RX65N スマートカードインターフェースモードで受信割り込みが遅延する

アルファプロジェクトのCPUボード「AP-RX65N-0A」を使用し、RX65Nのソフト開発をしています。

スマートコンフィグレータを使用して、SCI2をスマートカードインターフェースとして使用し

ソフトを組んだのですが、1byte受信した時点でオーバーランエラーが発生し、それ以降のデータが受信できません。

 

オシロを使い受信割り込みのタイミングをみたところ、20byteのデータを受信した後に

受信割り込みが発生していました。

通常であれば、1byte受信した時点で受信割り込みが発生するものと思います。

 

受信データについてはオーバーランエラーは発生するものの最初の1byteは正常に

RDRに取得できていました。

 

現象としては受信割り込みが遅延しているかのようです。

対処方法などご教授いただけないでしょうか?

 

スマートコンフィグレータの設定値は以下の通りとなっています。

データ長:8bit

パリティ:偶数

データ転送方向:LSBファースト

受信データ・レベル設定:標準

ブロック転送モード:ノーマル

GSMモード:ノーマル

転送クロック:内部クロック

ビットレート:26882bps

ビットレートモジュレーション機能:無効

SCK2端子機能:クロック出力

送信データ処理:割り込みサービスルーチンで処理する

受信データ処理:割り込みサービスルーチンで処理する

TXI2優先順位:レベル5

RXI2優先順位:レベル5

受信エラー割り込み許可(ERI2):有効

ERI2優先順位:レベル5

コールバック送信完了:有効

コールバック受信完了:有効

コールバック受信エラー:有効

 

クロックの設定は以下の通りです。

発振子:24MHz

PLL分周比:×1

逓倍比:×10.0

FCLK:1/4 60MHz

ICLK:1/2 120MHz

PCLKA:1/2 120MHz

PCLKB:1/4 60MHz

PCLKC:1/4 60MHz

PCLKD:1/4 60MHz

BCK:1/2 120MHz

 

スマートカードインターフェース信号をオシロでみたところ

SCK:10MHz

IO:26882bps(1bitデータ長 37.2usec)

 

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

  • brotherさん、こんにちは。NoMaYと申します。

    まず、ちょっと確認しておきたいのですが、以下の「受信割り込み」が発生したタイミングをどう確認されたか知りたいです。RXスマートコンフィグレータが生成したConfig_SCI2_user.cの受信割り込みルーチンの先頭で、デバッグ用に確保した何れかのポートの出力をトグルさせてみて、それとRX2への受信入力データと一緒にオシロで見てみた、でしょうか?

    そういうことあれば、それはプログラムのどこかに、(1bitデータ長)37.2usec×8≒300usecを超える割り込み禁止時間がある、ということになるとしか考えられないです。(現時点では。)

    > オシロを使い受信割り込みのタイミングをみたところ、20byteのデータを受信した後に
    > 受信割り込みが発生していました。
    > 通常であれば、1byte受信した時点で受信割り込みが発生するものと思います。

  • NoMaY様、ご返信ありがとうございます。

    説明不足で申し訳ありません。
    「受信割り込み」の確認方法は、NoMaY様のおっしゃる通り、ボードのMonitorLEDに割り当てられている
    IOポート(PC0)の出力をトグルさせて、RX2と2CH同時に波形を取って確認しました。

    なるほど割り込み禁止時間ですね。別で1msecごとにタイマ割り込みを使用しているので
    そちらに間違いがないか確認してみます。
    現状仕様している機能(コンポーネント)はSCI2とタイマ(TMR0_TMR1)とPORTのみで
    割り込みを使用しているのはタイマのみとなります。
  • タイマ機能自体削除しましたが症状は変わらず、20byte程度のデータを受信した後に
    受信割り込みが発生し、1byteだけ正常に受信し、エラー割り込み(オーバーラン)が発生します。

    割り込みが禁止されている原因を調べる方法はございますでしょうか?
  • brotherさん、こんにちは。NoMaYです。

    割り込みが禁止されている箇所を探す方法は、ソースファイルをgrepする、開発チーム全員でソースファイルをレビューする、或いはデバッガでレジスタウィンドウのPSWのIビットとIPLxビットに気をつけながらデバッグする、あたりかと思います。

    念の為、RX65Nのハードウェアマニュアルで、SCIのスマートカードインターフェイスモードの説明をちょっと見てみたのですが、SCIのハードウェアとしては、受信割り込みを遅延させることを目的としたような、そういったハードウェア機能は無さそうですね。

    ところで、タイマを削除されたので、使用している機能(コンポーネント)はSCI2とPORTのみということになりますが、RXスマートコンフィグレータ以外で組み込んだ(或いはアルファプロジェクトのCPUボードのボードサポートパッケージのようなもので初めから組み込まれている)ソフトウェアライブラリなどはあるのでしょうか?そういったものが無いのなら、プログラムとしてはとても小さく、割り込みの許可/禁止の処理を見落としていた、という可能性も低いような予感がします。

    考えていて思ったのですが、「20byte程度のデータを受信した後に 受信割り込みが発生」の前に、送信動作が行われていたりしないでしょうか?

    というのは、実は、以前からRSPIの送信終了割り込みに関して違和感を感じていて、SCIの送信終了割り込みに関しても何か似たこと(グループ割り込み処理が異様に遅いかも知れない?)があるのではないか、と思い始めたからです。RXスマートコンフィグレータで、送信終了コールバックを無効にしてみたらどうなるでしょうか?

    RX65Nマイコンのみでオシロは使わず(配線も無し)にRSPI波形をELC/DMA/MTU0で取ってみた(RSPI signal logger)
    japan.renesasrulz.com/cafe_rene/f/forum5/5720/rx65n-rspi-elc-dma-mtu0-rspi-signal-logger

    RX231でのコード生成を利用した、RSPIモジュールの利用方法について(データのアクセス単位で混乱しています)
    japan.renesasrulz.com/cafe_rene/f/forum5/5670/rx231-rspi/31598#31598

    [追記]

    あっ、でも送信終了割り込み処理が遅いといっても、数μsec程度の筈ですね。300usec×20=6msもの割り込み処理にならないですね。6msも割り込みが保留されるのは、そういうタイプの原因では無いですよね、、、すみません、、、

  • NoMaY様、ご返信ありがとうございます。

    少し疑問点は残っているのですが、問題が解決できました。
    ありがとうございます。

    まずスマートカードインターフェスで使用する通信仕様はISO7816になり、
    対象カードに対してクロックを与え、RST信号をLowからHighに変えるとATRというデータを
    返してきます。このため、送信データを与えることなくデータを受信します。
    この最初のATRのデータ受信につまずいていました。

    この問題の調査としてRST信号を切り替える直前にE1オンチップデバッギングエミュレータで
    ブレークさせ、PSWのIビット・IPLxビット、SSRなどを確認して問題が無いことを確認して
    再実行して動作確認を行っておりました。

    どうやらこの調査方法に問題があったようです。
    ブレークを外し、そのまま実行したところ、正常に受信割り込みが入り、
    正しくデータを受信することができました。

    少し疑問ですが、どうやらデバッガでブレークをさせた後、再実行すると
    しばらく割り込みが効かない時間ができてしまうようです。これが6msec程度。
    (このあたり詳しい方がいれば教えてください。)

    NoMaY様、いろいろと考えていただきありがとうございました。
  • brotherさん、こんにちは。NoMaYです。

    ああっ、、、分かった。(と思います、、、) この6msの間は、割り込みが効いていないのでは無くて、プログラムの実行が一時停止しているのだと思います。ブレークポイントを設定したところから実行開始した場合の、デバッガとしては一般的な(というか避けられない)挙動だと思います。今回のカラクリの詳細は、以下のようなことではないかなぁ、という気がします。

    ●ブレークポイントを設定したところから実行開始する場合は、デバッガの内部処理として、一時的に(というか一瞬だけ)ブレークポイントを解除する必要がある。(そうしないと1命令も実行することなく、すぐにまたブレークしてしまい、全く先へ進めなくなるので。) そこで、ブレークポイントを設定したところから実行開始する場合は、デバッガの内部で以下のような処理が行われます。

    ブレークポイントを設定したところから実行開始する場合のデバッガの内部処理
    (1) 実行開始するところに設定されていたブレークポイントを一旦解除する
    (2) 実行開始するところの命令を1命令だけ実行する
    (3) 先ほどの(1)で解除したブレークポイントを復元する
    (4) 先ほどの(2)の続きの命令から再度実行開始する

    ●今回、ブレークポイントを設定してあった実行開始したところは、RST信号をLowからHighに変える為の、ポート出力レジスタへの書き込み命令ではないでしょうか、、、(上の(2)に該当します。)

    ●そして、今回、上の(2)と(4)の間で、6msの間、プログラムの実行が一時停止していたのではないでしょうか、、、(その後、おそらく上の(4)のまさに直後に、受信割り込みルーチンへと飛んだのであろうと思います。)

  • NoMaY様、ご返信ありがとうございます。

    大変勉強になりました。おっしゃる通りの動きです。

    (2)のところはまさにポート出力レジスタへの書き込み命令でアセンブラで「BSET #3,[R14]」になります。

    試しに(2)でブレークし、ブレークポイントを削除してから実行を再開した場合も正常に受信できました。
    この場合、(3)の動作が無いため、6msの一時停止が行われず、すぐに実行が再開できたものと思われます。

    これで疑問点が全て晴れました。本当にありがとうございました。