[Armadillo:07136] Re: [Armadillo-440] I2C通信で失敗する

[下村智範]

下村です。

ご回答ありがとうございました。
ダミークロック発行の意図は理解いたしました。

ダミー初期化は、動作不能なスレーブデバイスを救うための処理ですので
電源投入時のダミー初期化処理で、「Could not grab Bus ownership」が
発生するということは、根本的に何か設定ができていないのではないかと
思いますが、いかがでしょうか。

armadillo400.c のI2C-1の情報を以下のように書き換えて電源を投入してみました。
//------------------------------------------------------------------------------------------------------>
static struct i2c_board_info armadillo400_i2c2_board_info[] __initdata =
{
    {
        .type = "s35390a",
        .addr = 0x22,
    },
};

static struct mxc_i2c_platform_data armadillo400_i2c2_data =
{
    .i2c_clk = 400000,
};
//------------------------------------------------------------------------------------------------------<

クロックもスレーブアドレスも接続している機器に合わせて
修正しましたが、やはり結果は変わらずでした。

上記のように修正しても、I2C-1 スレーブアドレス = 0x30 が一度セットされて
ダミーコールされているようでした。
armadillo400.c以外にも設定箇所がございますでしょうか。
(armadillo400_gpio.cも確認しましたが、スレーブに関する処理は
ございませんでしたので、何も修正しておりません)


ダミー初期化に関してですが、本処理は稀なエラー処理になりますので
I2Cの接続が確認できていない現段階では、原因切り分けのために
はずしたいと考えております。
(しっかりとI2C接続が確立された後に、稀なエラー処理に対応したいと思います)

どのように修正すれば多機能に弊害なく初期化処理がはずせますでしょうか。

以上、よろしくお願いいたします。


> I2Cに関しては、「Armadillo実践開発ガイド 第2部」でも簡単にですが説明していますので、
> 参考にしてください。
> http://manual.atmark-techno.com/armadillo-guide/armadillo-guide-3_ja-2.0.1/ch02.html#_i2c
こちらはもう何度も読み返しております。
しかし、エラーやダミー初期化など正常系以外について一切記載が
ありませんので、今回の動作しない現象では参考になりませんでした。
おそらくですが、この仕様書に記載されているサンプルソースでも
バス競合が発生すると思います。

以上、よろしくお願いいたします。


2011年4月21日18:57 Takenoshita Koyo <email@hidden>:
> 竹之下です。
>
>> ダミークロックの発行は、Armadilloの電源投入時にI2Cスレーブデバイスが
>> 通信エラー/信号待ち状態になっているかもしれないから無条件で発行する
>> という理解で間違いございませんでしょうか。
> はい。そうです。
>
>> ダミークロックを受け取ったスレーブデバイスは、通信エラー/信号待ち状態
>> の場合は、復帰するために何かリセット処理を行わなければいけないのでしょうか？
>> それとも、ダミークロックは、I2Cの通信シーケンスを一通り流すため
>> スレーブI2Cモジュールが勝手(自動的)に、正常な状態まで行くだろうということを
>> 期待しているのでしょうか。
> 後者です。「スレーブI2Cモジュールが勝手(自動的)に、正常な状態まで行くだろうと
> いうことを期待」しています。
>
>> 通信エラー/信号待ち状態ではない場合は、何もしなくても良いということになり
>> ますでしょうか。
> 何もしなくても良いです。
> (I2Cアドレスが一致しない場合、いくらクロックが入ってもスレーブデバイスは何も
>  する必要がありません。)
>
>>> 上記のように、リード中にリセットが発生すると、RTCがバスを掴んだままとなります。
>> バスの制御はマスターデバイスという認識ですが、スレーブデバイスのRTCがバスを
>> 掴んだままになるのでしょうか。
> 特殊な状況ですが、スレーブがバスを掴んだままに、なりえます。
>
> I2Cは、SCLとSDA 2本の線で通信する方法です。
> SCLは常にマスタが駆動します。
> SDAはマスタが駆動したり、スレーブが駆動したりします。
>
> マスタとスレーブとの通信は、以下の手順で行います。
> 1. マスタがスタートコンディションを発行する。(SCL=Highの間に、SDAをHigh->Lowと変化させる)
> 2. マスタがアドレスバイト(8bit)を送信する (このとき、SDAを駆動するのはマスタ)
> 3. スレーブがACKを返す(このとき、SDAを駆動するのはスレーブ)
> 4. アドレスバイトの7bit目が1のとき
> 5. スレーブがデータバイト(8bit)を送信する(このとき、SDAを駆動するのはスレーブ)
> 6. 続いてデータが欲しい場合、マスタがACKを返す(このとき、SDAを駆動するのはマスタ)
> 7. スレーブがデータバイト(8bit)を送信する
> 8. データの転送を終了したい場合、マスタがNACKを返す
> 9. マスタがストップコンディションを発行する(SCL=Highの間に、SDAをLow->Highと変化させる)
>
> 5. の途中で、スレーブには電源供給したままで、マスタだけにリセットがかかると、
> スレーブが"バスを掴んだ状態"となります。
> Armadilloで想定しているのは、この状況です。
>
> そのため、起動時に以下のことをしています。
> - SDAにつながっているピンをinputにして (これを前回書いていませんでした。)
> - SCLに128回クロックを入れる
>
> すると、SDAはオープンドレインで、かつ、プルアップされているので、
> スレーブがLowに駆動しなければ、SDAはHighになります。
> この状態でSCLにクロックを入れると、常にNACKを返している状態(8.)となります。
> そのため、スレーブデバイスがもし、5. の状態であったとしても、
> リードを完了するであろう、という想定です。
>
> I2Cに関しては、「Armadillo実践開発ガイド 第2部」でも簡単にですが説明していますので、
> 参考にしてください。
> http://manual.atmark-techno.com/armadillo-guide/armadillo-guide-3_ja-2.0.1/ch02.html#_i2c
>
> --
> Koyo Takenoshita
>
> _______________________________________________
> armadillo mailing list
> email@hidden
> http://lists.atmark-techno.com/cgi-bin/mailman/listinfo/armadillo
>