”かふぇルネ“はルネサス製品に関してユーザ同士が自由に会話をするツールであり、回答者はルネサス社内外の方たちとなります。ルネサス製品やソリューションに関して正式な回答をご希望の場合は、ルネサス技術サポート問合せをご使用ください。
短期間に度々失礼します。
ちょこです。
>シミュレーターで正常動作を確認
基本的に、シミュレータでは論理の確認しかできません。アナログが関係した項目は対応できません。
例えば、電源電圧がおかしかったら、デバイスでは誤動作する可能性があります。これに関係して、電源ラインにはバイパスコンデンサは入っているか、REGC端子には指定された容量が接続されているかを確認してください。
あと、INTP0端子にはプルアップ抵抗はつけてありますか（RL78のピンのところで波形は確認しましたか）。シミュレータではハイインピーダンス状態の入力はきちんと処理できなかったかと思います。また、チャタリング入力もできなかったと思います。
>また開発当初は型番R5F100LCxxxの仕様を想定して・・・
プログラムメモリの容量で、Mirror領域のアドレスがかわるので、対象デバイスにきちんと整合した設定でビルドしてください。
以上、さっと思いついたことをコメントしました。
Y.N@MCさん、こんにちは。NoMaYと申します。外部割込み等が動作しませんでした、という文面からでは余り状況が良く分かりませんでしたので、ソースの内容やシミュレータの動作を見ての推測ですが、こういうことでしょうか？(0) mainのスーパーループが回っていことはStatus LEDの点滅にて確認済み(1) P137(INTP0)に立下りエッジの信号を入力した(2) プログラム動作の期待値はP76の出力がロウ→ハイと変化するはず(3) しかし実際はロウのままとなる(オシロでトリガを設定して待ってみても掛からなかった？)ソースの内容を見た印象ですと、足を曲げてしまって使えなくしてしまったマイコンの代替のマイコンが届くまでの机上デバッグとしてやっておいた方が良さそうなこととして、以下のようなことはどうだろうかな、と思いました。(A) 回路図の見直し(回路図上でちゃんとP137やP76と接続されているか？)(B) パターン図の見直し(パターン図上でちゃんとP137やP76と接続されているか？)(C) 導通チェック(実基板にてちゃんとP137やP76と繋がっているか？)それから、実機ではデバッガは御使用では無いでしょうか？というのは、ソースの以下の箇所にブレークポイントを設定すれば、入力系に何かあるのか(←ブレークしない時)、それとも出力系に何かあるのか(←ブレークする時)、を判断しやすいかと思いました。r_cg_intc_user.c
static void __near r_intc0_interrupt(void){ /* Start user code. Do not edit comment generated here */ int_trigger = 0x01; /* End user code. Do not edit comment generated here */}
お二方とも色々とアドバイスありがとうございます。
結果から言いますと、いまいち納得できない形でしたが解決しました。
昨日夕方ごろ近場でR5F100LFAFAの在庫を融通していただけましたので基板に実装し修正コンパイルと書き込みを繰り返し検証を行っておりましたが依然変わらずの状態でした。
そのため比較的挙動の分かり易い部分からと、セーフティースイッチの切り替え処理部もスイッチを操作してもセーフティ解除LED等が反応していなかったのでifの条件から出力ポート読み込み!P12_bit.no0とチャタリング防止カウンタの!safety_ccを外しコンパイル、書き込みをしたところすべて正常に動作するようになりました。
その後、変更を加えたセーフティスイッチ切り替え処理のif条件に!P12_bit.no0と!safety_ccを戻して原因の詳細をと思っていたのですがif条件を戻しても正常な動作をしており、現状再現性の無いものなので原因究明は諦める事となりました。
今回あやふやなまま解決してしまいましたのでこれを機にデバッガを購入してオンチップデバッグ環境を整えようと思います。
協力いただきありがとうございました。
チョコです。
スイッチのチャタリング防止処理がおかしいのではないかと思われます。スイッチの検出をエッジ検出割り込みで処理しているだけだと、チャタリング防止はできません。int_triggerをr_cg_intc_user.cでセットして、main参照したり、クリアしているだけのように見えます。気になるのは、立下りエッジ検出割り込みで設定したint_triggerを確認してクリアした後で、検出エッジを切り替えているようです。問題は、押したときに立下りエッジだけではなく、チャタリングで立ち上がりエッジが検出されている可能性が考えられることです。少なくとも、最初の割り込みはスイッチを操作したことに起因しているので、それを処理するのは構わないのですが、そこから数十ミリ秒の期間はチャタリング防止で、エッジ検出割り込みを禁止しておく必要があります。ここらを検討してみてください。もしくは、エッジ検出割り込みは使わないで、数十ミリ秒以上の定周期でスイッチの状態を読み込み、例えば、変数に右から取り込んでいきます。そうすると、xxxxxx10ならスイッチが押されたこと（ON)を検出し、xxxxxx01ならスイッチがOFFになったことを検出したことになります。ちなみにxxxxxx11は押されていない状態が続いていて、xxxxxx00は押され続けているいることになります。xxxxxx10やxxxxxx01でフラグを設定してください。
ちなみにシミュレータでは、チャタリングは発生しないので、確認にはなりません。チャタリングはメカニカルな問題なので、いつも同じように発生するとは限りません。
また、IIC01を使われているようですが、その制御に問題があります。INTIIC01で指定された数のデータの送信完了でfl_i2c_txを0x01にすることで、送信完了を知らせていますが、これを確認して、きちんと制御しているところが見当たりません。fl_i2c_txは、R_IIC01_Master_Sendを呼び出す直前で0x00にすべきです。また、U_I2C_Sendを呼び出して戻ってきたら、fl_i2c_txが0x01になるのを待つ必要があります。R_IIC01_Master_Send（つまりはU_I2C_Send）から戻ってきた段階ではデータの送信は完了していません。単に、スレーブのアドレスの送信が始まっただけです。ここらは、理解されていますか。
以上、気になったところをコメントさせてもらいました。
チョコ様
ご指摘ありがとうございます。
また、ソースコードが散らかっていて申し訳ないです。
今回製作しておりますものが出力が40本ほどある名刺サイズの舞台演出用の火薬の点火装置(ライフル・マシンガン等用)でして操作する人間が素人からプロまで様々であり、プロの場合は演出に合わせてトリガースイッチ操作で数十ミリ秒の入力を意図的に行う方もいる上、確実に停止処理を行わないといけない為チャタリング防止処置が迷走しておりました。
原則としてチャタリングしないスイッチの利用ということにしておりますが、安全処置の為にもご紹介頂きました定周期による複数回サンプリングであれば仕様要求を満たせそうですので利用させて頂きたいと思います。
またI2Cの送信処理に関してですが今回の装置の構造上スレーブ側から必ずしも応答があるとは限らず、さらに点火信号を出力した際に出力段回路から最大24V5Aの出力が瞬間的に流れマイコン周辺のシールドエリアから外に伸びスタックされている別基板に接続される形のI2C経路にノイズが乗る可能性が高いため点火処理に影響が出るのを極力排除するように制御を行わず投げっぱなし処理になっています。
なのでI2Cマスターからの通信はすべて期待動作となりスレーブ側でデータやエラーのチェックに再度問い合わせによる値の合致確認等を行うようになっています。
シリアル通信に関してはテスト機納品後に最終的な仕様調整が入る予定のため、出力本数の削減や基板レイアウト変更が可能であればUART通信に変更する予定です。
細かなところまで確認とご指摘ありがとうございました。
>定周期による複数回サンプリングであれば仕様要求を満たせそうですので利用させて頂きたいと思います。
サンプリング周期は十分検討してください。
>またI2Cの送信処理に関してですが・・・投げっぱなし処理になっています。
何か誤解があるようです。気にしているのは、送信が完了していない（IIC01が送信中）のに、別の送信を開始する可能性がないかです。そうなると、最初の送信が途中で途切れてしまうことになります。（送信間隔が送信時間よりも長ければいいのですが。）
また、ノイズが考えられる環境ではI2Cはあまり推奨できません。というか、I2Cはボード内での通信用です。このような場合には、UARTをつかって、さらに、RS422のような平衡型にするべきでしょう。
御心配頂きありがとうございます。
I2Cのデータ長は固定で送信間隔はMCUプログラム内で最低でも必ず送信時間の3倍程度確保できるように調整しております。
I2C利用に関しては、ご指摘の通り当初はUARTを使用したかったのですが80x50mmサイズの基板3枚にR5F100LFAFAとその電源やリセットなどの周辺回路、出力40本分のPch MOSFETとそれをマイコン信号で駆動させる回路にMOSFET全体へ供給される電源の制御回路や各種コネクタなどを収めつつ出力に耐えられるパターン幅とMCU周辺のシールド及びアイソレートの結果使える端子の関係上I2Cしかなかった事による苦肉の策でした。
ソフトウエアUARTについても考えましたが、後々アップデートによる機能追加を求められた際にタイミング制御において支障が出る恐れがありましたので除外しておりました。
また、確かにRS422やRS485が理想的ですが物理的にインターフェースを実装出来るスペースが無いため利用は無理そうです。