アルファプロジェクトの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受信した時点で受信割り込みが発生するものと思います。
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-loggerRX231でのコード生成を利用した、RSPIモジュールの利用方法について(データのアクセス単位で混乱しています)japan.renesasrulz.com/cafe_rene/f/forum5/5670/rx231-rspi/31598#31598[追記]あっ、でも送信終了割り込み処理が遅いといっても、数μsec程度の筈ですね。300usec×20=6msもの割り込み処理にならないですね。6msも割り込みが保留されるのは、そういうタイプの原因では無いですよね、、、すみません、、、
brotherさん、こんにちは。NoMaYです。ああっ、、、分かった。(と思います、、、) この6msの間は、割り込みが効いていないのでは無くて、プログラムの実行が一時停止しているのだと思います。ブレークポイントを設定したところから実行開始した場合の、デバッガとしては一般的な(というか避けられない)挙動だと思います。今回のカラクリの詳細は、以下のようなことではないかなぁ、という気がします。●ブレークポイントを設定したところから実行開始する場合は、デバッガの内部処理として、一時的に(というか一瞬だけ)ブレークポイントを解除する必要がある。(そうしないと1命令も実行することなく、すぐにまたブレークしてしまい、全く先へ進めなくなるので。) そこで、ブレークポイントを設定したところから実行開始する場合は、デバッガの内部で以下のような処理が行われます。ブレークポイントを設定したところから実行開始する場合のデバッガの内部処理(1) 実行開始するところに設定されていたブレークポイントを一旦解除する(2) 実行開始するところの命令を1命令だけ実行する(3) 先ほどの(1)で解除したブレークポイントを復元する(4) 先ほどの(2)の続きの命令から再度実行開始する●今回、ブレークポイントを設定してあった実行開始したところは、RST信号をLowからHighに変える為の、ポート出力レジスタへの書き込み命令ではないでしょうか、、、(上の(2)に該当します。)●そして、今回、上の(2)と(4)の間で、6msの間、プログラムの実行が一時停止していたのではないでしょうか、、、(その後、おそらく上の(4)のまさに直後に、受信割り込みルーチンへと飛んだのであろうと思います。)