I2C通信がうまくいかないので、ロジック・アナライザをつないで見ていたら、addressの値が、１ビット右シフトされた値が出力されているようです。

なので、下記のソースのように指定する際に１ビット左シフトさせたら、正しい値が出力されるようになりました。

I2C i2c(D14, D15);

 
int main() {
//    while(1)
    {
        int value = 4095;
        //int value = 2047;
        char buf[3];
        buf[0] = 0x40;
        buf[1] = (value >> 4) & 0xff;
        buf[2] = ((value & 0x0f) << 4);
     
        printf("%02X %02X %02X\r\n",buf[0],buf[1],buf[2]);
    
        i2c.frequency(100000);
        i2c.write(0x60 << 1, buf, 3);
        printf("b\r\n");
    }
}

色々な方からフォローがあったのですが、arduinoと違い、１ビット右シフトさせてアドレスの指定の仕方は、mbedの仕様のようですね。 GR-SAKURA,GR-KURUMIでやり込んでいたので、やられたーって感じですね。

一週間、多忙のため反応できずに申し訳ありません。
急ぎませんので、しっかり対応願いします。

I2Cの確認で、I2C0,I2C1,I2C3各ポート動作しました。I2C0だけはプルアップ抵抗が付いていないので外付けです。
気になったのは、わざと存在しないアドレスで通信してnakにさせるとそこで止まってしまうことです。
接続していないときに止まってしまうのと同じ理由だと思います。

大変お待たせいたしました。
Araiさんに整理いただいた問題のうち、
>１）上記周波数設定
について、修正しました。

また、
>２）i2c->write(address, (char*)&regAddress, 1, true);　のふるまい
については、現在対応中です。

i2c.write(address, data, size, true);
i2c.read(address, data, size, true);

と、read/writeありますが、対応に時間がかかっているのはread側の処理です。
write側の対応だけでもあれば、という方がいらっしゃれば、更新版を準備します。

Hagimotoさん、オツカレサマです。

こちらでも確認、調査してみたいので、mbed-srcにアップしてもらえませんか？ （12/23に調べる予定です。）

Matsuokaさん、お申し出ありがとうございます。
>１）上記周波数設定
現状、上記の対応をしているものが最新です。
>２）i2c->write(address, (char*)&regAddress, 1, true);　のふるまい
こちらについては、以下の流れで進めます。

• ルネサスからARMさんに登録依頼をします(12/24)
  
• ARMさんで登録作業を対応します(通常2日～4日程度)

これまでの経験値では、12/27日にはmbed-srcとして更新されます。
しばらくお待ちください。

大変申し訳ありません。
12/22にRyo Hagimotoからコメントしました、mbed-srcの更新に関して、
現在、mbed-srcをupdateしても、
今回の修正が反映されない現象が確認されています。
原因を確認しております。
改善次第、ご連絡いたします。

今回の修正内容については、別の方法でご提供致します。
準備が出来次第、ご連絡致します。

お待たせ致しました。
12/22にRyo Hagimotoからコメントしました、mbed-srcの更新を反映したLibraryを、
暫定版として以下にアップ致しました。
http://developer.mbed.org/teams/GR-PEACH_producer_meeting/code/mbed-src-v442-pre/

上記URLにアクセスし、画面右側、
Repository toolboxからImport this libraryをクリックすると、mbed-src-v442-preを取得できます。
ご自身のprojectのmbed-srcを、mbed-src-v442-preに差し替えをお願い致します。
mbed-src全体の差し替えがNGな方は、大変お手数ですが、下記ファイルの差し替えをお願い致します。

libraries/mbed/targets/hal/TARGET_RENESAS/TARGET_RZ_A1H/

• PeripheralNames.h
• ethernet_api.c
• i2c_api.c
• objects.h
• pwmout_api.c
• serial_api.c
• spi_api.c
  
  mbed-srcのupdateに関する問題が解決するまで、
  お手数をお掛けいたしますが、よろしくお願い致します。
  

残念ながら、i2c->write(true)が、期待する動作になっていないです。

mbed-src r442がコレ。writeの最後にSTOPしています。（赤丸表示）

正常なのはコレ。（mbed LPC1114FN28）

対応が遅れて申し訳ありません。

まだ正式対応ではありませんが、

のふるまいについて暫定対応いたしました。

お手数ですが、以下の手順でご自身のソースを変更して頂ければと存じます。

１．Masao Hamanakaさんから展開がありましたように、ご自身のprojectのmbed-srcを
　　http://developer.mbed.org/teams/GR-PEACH_producer_meeting/code/mbed-src-v442-pre/
　　のLibrary暫定版へ差し替え願います。
２．以下のソースを開きます
　　mbed-src/targets/hal/TARGET_RENESAS/TARGET_RZ_A1H/i2c_api.c
３．465行目～475行目のコード

        /* RIICnSR2.STOP = 0 */
        REG(SR2.UINT32) &= ~SR2_STOP;
        /* RIICnCR2.SP   = 1 */
        REG(CR2.UINT32) |= CR2_SP;
        /* RIICnDRR read */
        value = REG(DRR.UINT32) & 0xFF;
        data[count] = (char)value;
        /* RIICnMR3.WAIT = 0 */
        REG(MR3.UINT32) &= ~MR3_WAIT;
        (void)i2c_wait_STOP(obj);
        i2c_set_NACKF_STOP(obj);

　　を以下に差し替えます

        /* If not repeated start, send stop. */
        if (stop) {
            /* RIICnSR2.STOP = 0 */
            REG(SR2.UINT32) &= ~SR2_STOP;
            /* RIICnCR2.SP   = 1 */
            REG(CR2.UINT32) |= CR2_SP;
            /* RIICnDRR read */
            value = REG(DRR.UINT32) & 0xFF;
            data[count] = (char)value;
            /* RIICnMR3.WAIT = 0 */
            REG(MR3.UINT32) &= ~MR3_WAIT;
            (void)i2c_wait_STOP(obj);
        } else {
            /* RIICnDRR read */
            value = REG(DRR.UINT32) & 0xFF;
            data[count] = (char)value;
            /* RIICnMR3.WAIT = 0 */
            REG(MR3.UINT32) &= ~MR3_WAIT;
        }
        i2c_set_NACKF_STOP(obj);

４．509行目～511行目のコード

    　　i2c_stop(obj);
    　　(void)i2c_wait_STOP(obj);
    　　i2c_set_NACKF_STOP(obj);

　　を以下に差し替えます

        /* If not repeated start, send stop. */
        if (stop) {
            i2c_stop(obj);
            (void)i2c_wait_STOP(obj);
        }
        i2c_set_NACKF_STOP(obj);

５．ソースをセーブしてコンパイルします

i2c_set_SR2_NACKF_STOP（）のコードが公開されていないのでは?

i2c_set_SR2_NACKF_STOP()が無いエラーが発生します...。

Error: Undefined symbol i2c_set_SR2_NACKF_STOP (referred from i2c_api.c.RZ_A1H.o).

preで公開されるまで待つことにします。(-.-)

大変申し訳ありませんでした。
i2c_set_SR2_NACKF_STOP()はi2c_set_NACKF_STOP()の誤記でした。
本文を訂正致しましたので、ご確認お願いいたします。

安直には言えませんが、私の場合には途中で停止します。
今夜から土曜日の午後までGR-PEACHとお付き合い出来ず、解析できません。
少なくても
i2c.write(acc_addr, dbf, 1, true);
i2c.read(acc_addr, data, 6, false);
を入れるとだめで、true、falseを除くと連続動作しそうです。

パッと見、動作しています。

（dataSize = 2 で試しました。）

    i2c->write(address, (char*)&regAddress, 1, true);
    i2c->read(address, (char*)data, dataSize);

切り分けが出来ていませんが、以前紹介したRTOSと組み合わせた、ソフトを使用した結果。
1) GR-PEACH_test_on_rtos_not_fixed_yetをテスト
http://developer.mbed.org/users/kenjiArai/code/GR-PEACH_test_on_rtos_not_fixed_yet/
2) mbed-srcとmbed-rtosをGR-PEACH最新版に
3) 上記、変更をi2c_api.cppに対して実施
4) L3GD20とLIS3DHのRevisionをそれぞれひとつ前のものに戻し、true/false挿入

1) 上記で数秒で停止
2) false削除→数秒で停止
3) true/false両方削除→一晩、6時間以上連続動作

ご報告ありがとうございます。

現在原因調査中なのですが、こちらの環境(OSなし)では動作が停止するような現象は発生致しませんでした。
以下のような処理で試して、10分以上連続動作いたしました。

while(1) {
    i2c.write(acc_addr, dbf, 1, true);
    i2c.read(acc_addr, data, 6, false);
}

OS絡みの可能性も踏まえて原因調査中です。

まだ完全な切り分けが出来ていませんが、RTOS側には少なくても一つ問題があることがわかりました。
RTOSに関する議論に問題点をアップしました。
http://developer.mbed.org/forum/team-886-GR-PEACH_producer_meeting-community/topic/5365/
I2Cに関して完全に白とはまだ断言できません。
動作が停止した際にSCLとSDAラインがLOWのままになっている現象も確認出来ています。
これがRTOS側の原因で影響を受けているだけなのかは現時点不明です。

新たな問題点が発覚したので、その内容を紹介するために、GR-PEACH_test_on_rtos_not_fixed_yetをRevision-Upしたいのですが、
http://developer.mbed.org/teams/GR-PEACH_producer_meeting/code/mbed-rtos-v60-pre/
http://developer.mbed.org/teams/GR-PEACH_producer_meeting/code/mbed-src-v442-pre/
をLibとして用いているので追加修正しているために私のプログラムを公開できません。
上記Yamanakaさんの回答の記述を反映した最新版を同じ名前でupdateしてもらえませんか?
RTOSも一緒にupdate願います。

mbed-src-v442-preおよびmbed-rtos-v60-preをアップデート致しました。
内容が重複しますので、こちらを参照ください。

Hamanakaさん
アップデートご苦労様でした。

アップデートされたプログラムを使用した結果をもとに、状況を再整理してみました。
このスレッドはI2Cの機能が上手く動作するか否かに関して議論してきましたが、私の責任もあり議論がRTOSの問題なのかI2Cの問題なのか切り分けが上手くいかない中で、予断を持って話を進めていました。
現時点での私の結論は、
①　rtos関連では別途議論があるように、まだ何か問題点がある
②　I2Cの問題が解決したか否かは現時点では不明
③　新たな問題が発覚
ということになります。
先ず、rtosとの問題分離のために下記プログラムを作成し公開しました。

このプログラムは、I2Cをrtosを使用しないで連続で動作させるプログラムです。
比較のために、NucleoF401REでの動作確認も実施しました。
結論は、GR-PEACHでは１時間１１分３０秒後に停止しまがNucleoF401REは少なくてもそれ以上動作継続します。
停止原因は、1usタイマーのオーバーフロー処理の問題と思われます（そもそもGR-PEACHではオーバーフロー処理がないと思われる）。
これが上記③の問題です。
実はGR-PEACHに限らず、すべてのmbedライブラリのRevision90もしくは91では、この問題が過去に発生しています。
http://developer.mbed.org/users/kenjiArai/notebook/lpc1114fn28---suggestion-for-improvement/#
現在のmbedライブラリーでは、この問題は解決していますが、GR-PEACH専用のmbed-src-V442-preでどうなっているか気になります。
しかし同じ上記公開プログラムをNucleoで動作させると1時間11分問題は発生しないことから、GR-PEACH特有の問題と思われます。
②の結論は、③が解決しないと何とも言えないということで判断保留とします。

③に関しては、Akagawaさんが原因解明してくれましたので、解決済。
(プログラム修正をどうするのかは現時点不明）
http://developer.mbed.org/forum/team-886-GR-PEACH_producer_meeting-community/topic/5344/?page=1#comment-26841
①rtosの問題解決のためにHW貸し出しを実施。
http://developer.mbed.org/forum/team-886-GR-PEACH_producer_meeting-community/topic/5365/?page=1#comment-26821
従って、I2Cの主題②の問題も中の人の検証で白黒付くでしょうから、結果報告を待ちたいと思います。

Araiさん
状況の整理、ありがとうございます。
ご報告いただいた、①については、③が原因で発生することがわかり、現在解析中です。
①の内容については、RTOSに関しての議論
③の内容については、delay_ms()のバラツキ
にて情報を展開します。

②については、公開いただているGR-PEACH_test_wo_rtosを元に、
明日、平行して原因解析を行います。

I2Cの主題である、
＞②　I2Cの問題が解決したか否かは現時点では不明
について、コメント致します。

【現象】
i2c.write関数の第4引数にtrueを指定すると、
途中でプログラムが停止する。

【原因】
原因は、us_ticker_read()が正常に機能していないことによるものでした。

【対策】
us_ticker_read()の対策内容は、以下を参照ください。
RTOSに関しての議論
delay_ms()のバラツキ

【長時間稼働の結果】
確認環境
・ハードウエア
　- GR-PEACH + Araiさん借用LCDボード
・ソフトウエア
　　- GR-PEACH_test_wo_rtos
　　- GR-PEACH_test_on_rtos_not_fixed_yet

上記ソフトウエアに、対策コードを組み込み、
長時間稼働(8時間)を実施した結果、I2Cは問題なく通信を継続しておりました。(通信はターミナル出力およびLCDで確認)
Yamanakaさんから展開しました、i2c->write(address, (char*)&regAddress, 1, true);のふるまいに関しては問題ありませんでした。
「known issues」「fixes No.30」に情報を記載しました。

【今後の対応】
上記のとおり、I2Cのwriteに関する問題については解消しましたが、I2Cのreadに関する問題が残っています。
⇒「known issues」の「defects No.1」
このI2Cのreadの問題を継続して調査しています。