R5F61644A　H8SXのIICのBUSYフラグについて

すと@konです。

何らかの原因によってIICがハングアップしたのなら、リセットしたほうがいいと思います。
（通常、こうした状態にはなりません）

> IIC20.ICCRB.BIT.IICRST = 0;//②IICRST＝0（内部リセット解除）

こちらを

IIC20.ICCRB.BIT.IICRST = 1;//②IICRST＝1（内部リセット）

にして、リセットしてみてはいかがでしょうか。

ＳＳです。

上記の現象は、ハードウェアの問題か？ソフトウェアの問題かで対処方法が違います。

自分が体験したのはハードウェア絡みで起こってる時です。

まず、上記の現象が発生している時のSDA端子とSCL端子の状態を確認すると良いと思います。

SDAが’L'の場合のは、SCL端子よりクロックを与えると解決すると思われます。ルネサス様の回答にも有ると思います。


SCLが’L'でロックしている場合は、IICのデバイスのどれかがマスターモードでハングアップしていると思います。

まず、ソフトウェアの問題か、ハードウェアの問題か切り分けましょう。
すと様の言う通り、リセットすると解除される場合は、
ソフトウェアの問題なのでウォッチドックが発生しているかとか、確認された方が良いと思います。

maaki05さん

ハードの可能性だったとして、

発生状況がわかりませんけども
オシロでSCLとSDAの立ち上がりを確認してみるのもいいかもしれません。
波形の立ち上がりに問題があって、ストップコンディション波形が崩れているかもしれません。

FPGAなどが相手の場合、
同じプルアップ抵抗値にしているにもかかわらず、
SCLの立ち上がりが異様に遅くなることがあります。
(FPGAのI/Oの構造によってクロック側に容量が多く付く事があります)

その場合は、SCLのプルアップ抵抗をSDAよりも小さいもの(半分～1/10程度)に変えるとSCLとSDAの立ち上がりが揃って正常動作することがあります。

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

すいません。今回の目的をお伝えしますと
H8SX（Master）とRL78G13（slave）とマイコン間の通信をしております。
その通信中にノイズ等の影響で
以下のif分で真となった場合に
ソフトの対策としてどのようにリトライさせようか検討しており、そこでBBSYが変化しない為困っておりました。
if(IIC20.ICCRB.BIT.BBSY != 0){}

現状、ハードウェアの原因もあり波形もなまりやすく
ノイズ等にも弱い状態です。
ハードの対策も同時に進めておりますが
SCL、SDAから線を伸ばしたりすると通信がこける為
対策を考えております。

投稿時のコードが
リトライ時に実行しているコードです。
その時の状態とポートレベル・レジスタ値は以下の通りです。
よって、IIC20.ICCRB.BIT.BBSYの最上位bitが落とすことができておりません。

あと、すとさんの内部リセットを1にするのを
実施したところSCL\,SDAはともにHとなり、その後BBSYを落としに行ってみましたが変化なしでした。

通信を復活させるのにも限度があるのでしょうか？
参考にリトライをする前の波形（通信がこけた瞬間）を添付します17:03分ファイル。

ウオッチドッグは未実装です。

投稿時の初期化コード実行時の波形も添付します。17:27分ファイル

<コード実行時の状態>
●＝状態です。
{
●IIC20.ICCRB.BIT.BBSY==D5
●SCL=L\,SDA=L

IIC20.ICCRB.BIT.IICRST = 1;//①IICRST＝1（自局のSCL/SDA出力ラッチ解除）
●IIC20.ICCRB.BIT.BBSY==FF
●SCL=H\,SDA=H

IIC20.ICCRB.BIT.IICRST = 0;//②IICRST＝0（内部リセット解除）
●IIC20.ICCRB.BIT.BBSY==FD


//③SCL/SDA=Highレベル確認（兼用端子のポート入力チェック）

while ( IIC20.ICCRB.BIT.SCLO != 1 ) {/* SCL=High? */

}

while ( IIC20.ICCRB.BIT.SDAO != 1 ) {/* SDA=High? */

}


IIC20.ICCRA.BIT.MST = 1;//④マスタ送信モードに遷移（MST=1、TRS=1ライト）

IIC20.ICCRA.BIT.TRS = 1;


IIC20.ICCRB.BIT.BBSY = 1;//⑤開始条件発行（BBSY＝1、SCP＝0ライト）

IIC20.ICCRB.BIT.SCP = 0;
●IIC20.ICCRB.BIT.BBSY==D5
●SCL=L\,SDA=L


while ( IIC20.ICCRB.BIT.SCLO != 0 ) {//⑥開始条件発行確認（SCLO＝0確認）

}


IIC20.ICCRB.BIT.BBSY = 0;//⑦停止条件発行（BBSY＝0、SCP＝0ライト）

IIC20.ICCRB.BIT.SCP = 0;


●SDA=約25usHigh
●SDA波形の立ち上がりから10us遅れで
●SCL=約20usHigh

●SCL:____┌──┐__←こんな感じです。
●SDA:__┌──┐____



IIC20.ICSR.BIT.STOP = 1;//⑧停止条件発行確認（STOP＝1確認）

IIC20.ICSR.BIT.STOP = 0;//⑨STOPフラグクリア（STOP＝0ライト）
}

4EbgEwQ7zsygxu2U_A0261.jpg

DIdnH1cJOkBXhiCv_A0260.jpg

ＳＳです。

いろいろご苦労されているようですね。

基本的に、波形の立ち上がりがナマっていますが、
通信が出来ないほどでは無いですね。

とりあえず、プローブを繋ぐのでしたらプルアップ抵抗を小さく変えましょう。

それと、不思議なのですがIICの波形が通信していない時Low側に成っていますが、間違いないですか？
基本的にプルアップ抵抗が有り、通信していない時は、全てのデバイスはハイ・インピーダンスだと思うのですが・・・
失敗してSDAがLowになってるんですかね？？


後、テクニカルアップデートに以下の事が書いて有りました。参考までに

IICRST によるレジスタ初期化
・ ICCR2の IICRSTに 1をライトすると、ICCR2の SDAO\, SCLOは 1セットされます。
・ マスタ送信モードおよびスレーブ送信モードにおいて、IICRST に 1をライトすると、ICSR の TDREは 1セットされます。
・ IICRST=1 によるリセット期間中は、ICCR2の BBSY\, SCP\, SDAOへのライトは無効です。
・ IICRSTに 1をライトしても、ICCR2の BBSYビットは 0クリアされません。しかし、SCL\, SDAの端子状態によっては、停止条件( SCL=High かつ SDA立上り )が生成され、結果的に BBSYが 0クリアされる場合があります。また、他のビットも同様に、影響が発生する場合があります。
・ IICRST=1 によるリセット期間中は、データ受送信を停止します。しかし、開始条件\, 停止条件\, バス競合負けを検出する機能は動作しています。SCL\, SDA へ入力された信号によっては、ICCR1\, ICCR2\, ICSR の状態が更新される場合があります。

SSさん有難うございます。

波形のLow部分については失敗している通信に状態です。

やりたいのは
この状況からどうやれば復帰できるのか
レジスタをリセットできるのかを探っています。

実際の確認時はノイズや線長を伸ばし、
わざと通信失敗状況にしています。

その時、SCLがLowになり、BUSYフラグも落とせず
I2C割り込みが入りっぱなしでメインループが正常に
ループしない状況におちいってしまします。

そもそもBUSYを落とそうと投稿時のコード処理を
実行してますが、波形でもわかるように一瞬でLowに落ちてしまうのは、どんな原因が考えられるんでしょうか？

ＳＳです。

よくあるのは、スレーブ側が必要クロック数が受け取れずにデータの出力中で止まってる事が有ります。

EEPROMなどでも起こるのですが、たまたまノイズが入りマスタ側が失敗してしまい。９クロックが正常に出力されない場合に、SDAを最後のデータでデットロック状態に入る事が考えられます。

今回の場合だと、RL78側が正常に終了していないのではありませんか？
スレーブ側もタイムアウトしてIICのレジスタにリセットを行なってみてはいかがでしょうか？

幸いに、スレーブ側もマイコンですし、ご自分でソフトウェアを変更出来るのでしたら、割り込みスタートでタイマを設定し、タイムアウト時間が経過しても正常終了していない場合に双方でリセットを行うのが懸命だと思われます。

自分の場合は、マルチマスターモードでIICを使用しなければならず、更に海外のプログラムが入っていたため、そちらのマイコンとの間にIICのスイッチを挿入して逃げた事も有りました。
海外のプログラムは、正常に動く事が前提になっているものが多く、ノイズで止まったりするとリセットしかないなんてモノが多いですからね。


IICもIOポートで、動作させたり、FPGAだったりですので、その時々で対処方が別れますが、なるべくタイムアウトで逃げて、無限ループは入れない事ですね。

SSさん、ご丁寧にほんとにありがとうございます。

実際試したことで申しますと、
通信失敗状態にH8SXのMaster側で初期化処理を繰り返し、RL78(slave)マイコンのみをハードリセット（RST端子をGND）させてみました、
SCLのLow波形に変化が見られるかと思いましたがダメでした。

RL78側のソフトも対応できるか確認してみます。

スタッフのチョコです。

maaki05様の回答番号６にコメントさせていただきます。

全体像がつかめないので，気になったところだけをコメントいたします。

波形を見させていただきましたが，かなり鈍っていて，IICバスのスペック（立ち上がり1μｓ）を満足していないように見えます。問題を再現するためとはいえ，これでは，新たな問題が起こってしまう危険性があります。

左側の波形を見ると，2つ目のデータで9クロック目に変なヒゲがありますが，これでマスタはSCLと認識していないのに，スレーブはSCLと認識したりしてないかが気になります。（どの程度の幅か不明確ですが，規格を満足していないと思われますので，その後の正常な動作をするかは不明です。）



> IIC20.ICCRB.BIT.BBSY = 1;//⑤開始条件発行（BBSY＝1、SCP＝0ライト）

> IIC20.ICCRB.BIT.SCP = 0;
> ●IIC20.ICCRB.BIT.BBSY==D5
> ●SCL=L\,SDA=L

ICCRBレジスタでスタートコンディション（開始条件）を発行するときにはビット操作ではなく，MOV命令を用いるはずですが。


> IIC20.ICCRB.BIT.BBSY = 0;//⑦停止条件発行（BBSY＝0、SCP＝0ライト）

> IIC20.ICCRB.BIT.SCP = 0;
>
>
> ●SDA=約25usHigh
> ●SDA波形の立ち上がりから10us遅れで
> ●SCL=約20usHigh
>
> ●SCL:____┌──┐__←こんな感じです。
> ●SDA:__┌──┐____

ここもストップコンディション（停止条件）発行はMOV命令にすべきはずですが。

この波形はスタートコンディション（開始条件）ですが。それを意図されていますでしょうか？
また，添付された右側の波形も左側が同時に立ち上っていることから，スタートコンディション（開始条件）と解釈される可能性がありますが，ここがリセットで，それに続く部分が正規のスタートコンディション（開始条件）と解釈できますが，その後の部分はどうなったのでしょうか。

チョコさんご丁寧にありがとうございます。

MOV命令の件は修正したいと思います。

お気づきのように、ヒゲの件もこちら確認しており、通信失敗の際は必ずでており、RL78のフィルタ設定でこのヒゲも変化します。ことからRL78のウエイト関連も影響しているのかとも想定してます。

全体像をお伝えしきれていなくてすいません。
あと、分かってきたこともありますので
あわせて記載します。

現在H8SX（Master）とRL78（slave）の基板があります。
そこではマイコン間通信はこけることはほとんどなく、
波形もきれいです。
その基板から、I2Cライン・電源を伸ばし別基板のRL78（slave）2個搭載の基板があり、この接続をすると波形が一気になまります。プルアップの定数やハーネスなど、ハードも見直し中ですが、通信が失敗した際のソフト対策が必要だと思っています。

その後、色々ためしました。
BUSYフラグは落とせていないのですが、通信でこけた際に
別基板のRL78をハードリセットしてやると、Masterからの通信が再開しています。

Masterと同じ基板のマイコンをハードリセットしてもダメだったのですが別基板のRL78のハードリセットで復帰するようです。

上記から、原因は別基板側のRL78の実装に問題あり？or対策？が必要かと思っています。

●そこでなのですが、
RL78のslave1台と通信する時と、RL78のslave3台と通信する時とでRL78（slave）側のソフトに何か設定の違いが必要でしょうか？

初歩的な質問かもしれませんが、現状はslave1台のケースと3台のケースが使用状況によって接続数が変わる為、slave側ソフトは同じ通信モジュールにしております。ハードSWでアドレスを変えております。

質問ばかりで申し訳誠にありませんが宜しくお願いします。