stlと申します。
RA2E1マイコンで簡易I2Cの機能を使用しています。デバッグを実行してみると、送信用のAPI関数の戻り値としては「成功」となりますが、オシロスコープでピンの出力を確認すると、SDAとSCLKの出力波形が確認できず、関数の実行タイミングで5Vから0Vに変化するだけでした。 この問題について何かわかることがありますでしょうか？
チョコです。
RL78は日頃使っていますが、RAは使ったことがありませんので、想像になりますが、コメントさせてもらいます。
おそらく、SCを使ってコード生成されていると思いますが、送信用のAPIは送信処理を起動するだけで戻ってきている
のではないでしょうか。
また、「SDAとSCLKの出力波形が確認できず、関数の実行タイミングで5Vから0Vに変化するだけでした。」は、
スタート・コンディションが発行された状態ではないかと思います。
つまり、通信が開始した時点までの波形しか確認していないのではないでしょうか。
通信が完了したことを確認して、そこまでの波形を確認されることをお勧めします。
以上
ご回答ありがとうございます。
>>通信が完了したことを確認して、そこまでの波形を確認されることをお勧めします。
送信用のAPIが、通信が完了までいかなくても起動した段階で「成功」を返してきている可能性があるということでしょうか？
tf様
プロジェクトを確認していただきありがとうございます。
>>・ボード上には水晶振動子16MHzとサブの水晶振動子32.768kHzが搭載されている
クロック関係?のことですかね。あまりこのあたりのことが理解できていないのですが、マイコンに搭載されているものだと思っていました。使用している基板に取り付けているということはないと思います。
>>オシロで波形を見ている時の横軸（時間/div）ですが、どの程度のレンジに設定していますでしょうか
だいたい100ms前後で確認をしています。レンジの設定がおかしい可能性も考えて、レンジをいろいろ変えてみての確認もしていますが、波形は確認できていないですね。
stl様このコメントから、クロック設定が抜けている感じします。そんな時はLEDの点滅プログラムが動くかを確認してみるのがいいですね。外部クロック設定で内部クロック使う回路設計だと動きません。PLLの設定範囲外の周波数を入れても動きません。
Shoji Yamamoto様
クロックの設定は自分で何かいじったつもりはなかったのですが(もしかしたら意図せず変更してしまっている可能性はありますが)、外部クロック設定になっているということでしょうか？
LED点滅は動作させてみて、上手くいきました。
Sugachance様
お答えいただきありがとうございます。
g_i2c0.p_api->openという書き方については、あまり知らなかったので、勉強になりました。
Shoji Yamamotoさま、stl さま
RA2E1は、内蔵オシレータでPLLも搭載されていないので、クロックの設定で問題あるとすると、サブクロック周りです。
FSPの設定でサブクロック→発振 の設定となっていました、
ボードにサブの水晶振動子が搭載されていないと、発振安定待ちで止まってしまいます。デバッガで、hal_entry.cまで飛んできていればクロックの設定の問題はありません。
stl さま
投稿頂いたプロジェクトを、実機で動かしてみましたが、1バイト目の送信（SLAVEアドレスの送信）の所は波形が出ました。
→割り込みコールバック関数に飛んできて、ABORTEDのステータスです。
（プログラムとしては、1つめの
while(i2c_writing == true){;}
で無限ループです。（EEPROMがつながっていない環境です）
FSPの設定には、問題は無いと考えます。デバッガでコールバック関数までは来ているとの事ですので、「測定の問題」ではないかと考えます。
SLAVEが応答しないとすれば、波形が出る時間は100us程度です。100msのレンジですと、画面に1本縦線が出る波形となると思います。stl さまの話では、1回立ち下がって終わりとの事でしたが、実行を掛けると最終的にはL張り付きの波形となりますか？
・最初はH
・Lに遷移する
・（100msのレンジだと）直ぐHに戻ってHで波形が終わる
といった感じ（基本H張り付きで、1本縦線が見える）様な波形にならないでしょうか。
10us/div（画面全体で100us程度）の横軸設定にして波形を観測してみてください。また、直ぐに波形は消えてしまうと思いますので、シングルトリガのボタンを押してからデバッガで実行を掛けてみてください。SCLは等間隔にHパルスが9発、SDAは、アドレスの設定に拠りますが2~3回の遷移が観測できると思います。
I2Cとは無関係ですが、プロジェクト内で、
unsigned char adpcm_data[10000] = {0};
64kBのデータバッファを確保しようとしていますが、RA2E1はRAMが16kBです。16kBのメモリで足りなさそうなら、他のマイコンを検討した方が良いかと思います。（コスト最重視のプロジェクトですか？）
変数名等を見ると、オーディオデータを再生させようとしているのかと思いました。RA2E1ですと、PWMで波形を作るつもりでしょうか（ものすごく短い時間周期でパルス幅を変えていかなければならないので、凄く大変な気がします）。RA2E1には非搭載ですが、RA2L1ですとD/Aコンバータが搭載されており、D/Aにデータを一定のタイミングで送るだけで、音声波形を出力できるかと思います。
（RA2L1の、D/Aは12bitで、変換時間30usなので、スペック的には33kHz、（上手く作ればですが）音声帯域としては、15kHz程度の出力ができるでしょうか。）
コストとの兼ね合いになりますが、RA4E1ですとRAMは128kB、D/Aの変換時間4usなので、ある程度リソースには余裕が出るかと思います（3.3Vのマイコンですので、5V要であれば選択肢には入りませんが）。
実際に確認していただきありがとうございます。
>>stl さまの話では、1回立ち下がって終わりとの事でしたが、実行を掛けると最終的にはL張り付きの波形となりますか？
オシロスコープをあまり使ったことがないので、分かっていないことが多いのですが、tf様が行っている設定とは違うことをしているかもしれません。モードは、今までオートトリガーでやっていました。おおよそどの時間のレンジに設定しても、最初はH➔Lに遷移するというだけでした。縦線の波形ではなく、横一直線の波形のみです。
モードはシングルモードがおそらくないのですが、その場合はノーマルモードでも良いのでしょうか？ノーマルモードでやってみると、デバッグボタンを押したタイミングで、SDAとSCLの波形は確認できたのですが、実行ボタンを押した場合はなぜか波形が確認できなかったです。
>>プロジェクト内で、
オーディオデータをEEPROMに格納して、データを取り出しながら、オーディオ再生が出来るかを試みています。データバッファの64KBという数字はあまり考えずに宣言していたのですが、オーディオデータのサイズが大きいので、何回かに分けてデータを送信しようと思っています。
このマイコンは、今後の製品開発への採用が決まっているという状況ですね。
>>変数名等を見ると、オーディオデータを再生させようとしているのかと思いました。RA2E1ですと、PWMで波形を作るつもりでしょうか
RA2E1では、オーディオ再生用のAPIが用意されているので、そちらを使用して音声再生が出来ます。実際に動作させてみて、音声の再生は上手くいきました。
stl様EEPROMのデータをマイコンRAMに一度展開してそこから再生ということですね。本筋で言えばI2Cアクセスの解決をしたいということへの回答を書くべきなのですが・・・RAMが足りなくてマイコン変更するくらいならFeRAM（FRAMという場合も）のSPI接続ならこの型式でも遅くておも6MHzくらいのクロック速度でデータ取得できますよ（SPIポートが空いてればの話ですが）。それならマイコンのRAMを大きくする必要なく、上手くやれれればDTCでFRAMから直でタイマのコンペアマッチレジスタを変更できると思います。つまりCPUは開始と終了待ちで、ほぼほぼ他に処理が回せるようになります。サイズも1チップで512Kバイトまであります(例としてCY15B104Q-SXI)。あとはFatFsライブラリを使ってSDカードをSPIで繋ぐなどもてかなと思います。
FeRAMというのは、マイコンに搭載されているものではなく、外付けのメモリでしょうか？現在使用しているもので上手くいかなければ、教えていただいた方法も考えたいと思います。
stl様外部に接続するシリアル通信タイプのメモリで、SPI接続タイプの不揮発メモリの１つにFeRAMというのがあります。他にはFlash ROM、もちろんEEPROMもSPI接続タイプはあります。もっと言えばボタン電池バックアップのSRAMチップもありますね。Flash ROM、EEPROM、FeRAMそれぞれ、利点と欠点があるので使い方で選択されるのがよろしいかと思います。例えばデータはただ外部にあるだけならFlashがいいのかなと思います。頻繁に書き換えるならFeRAMがいいのかなと思います（ただし読み出し回数制限があります）。データサイズが大きいならFlashROM一択な気がします。