I2Cは1Mohmでプローブまたはロードされた場合にのみ機能します


9

msp430fr5847(マスター)とI2Cチップが不明なスレーブセンサー(産業用センサーの一部)の間の通信をトラブルシューティングしようとしています

データがすべてゼロで返されるセンサーの新しいバッチで問題が発生していますが、Saleae logic pro(2Mohm、10pf)、またはオシロスコープ(10Mohm、50pf)でトラブルシューティングしようとすると、システムはプローブ時に完全に機能しますSDAピン。

さらにトラブルシューティングを行うと、SDAとグランドの間に1Mオームの抵抗を追加しても回路は正しく機能しますが、10pfまたは100pfのコンデンサを追加しただけでは機能しません。

3.3vレールに4.7kのプルアップ抵抗を使用しています。

この問題の原因となるもの、および意図せずに問題を修正せずにトラブルシューティングを行うために実行できること。


編集:19/07/2017これが私の信号のクイックスコープトレースです。

SDAをプローブするだけでボードが機能し、SCLをプローブするか、または割り込みラインがボードを適切に動作させないことについて、私が言及するのを忘れていました。

SDAおよびSCLのスコープトレース


編集:21/07/2017

プロットが厚くなり、別のオシロスコープを接続しても回路が正しく機能しないように見え、唯一の違いはACKが送信されていないことです。

新しいスコープ画像

上の図では、回路が正しく動作していない場合の青と緑のトレースがSCLとSDAです。黄色とピンクのトレースは、SaleaeロジックもSDAピンとグラウンドに接続したときのものですが、USBを接続していません(グラウンドループを回避しようとしている)。

センサーにもう少し背景を追加するのは、メーカーから購入した工業用圧力センサーです。私たちは以前に、これらのPCBをセンサーの最初のバッチで設計およびテストしました。最近、新しいバッチを受け取り、これらの問題が発生しています。私は、PDFデータシート、内部センサーがZSC31014または類似を使用していること(データシートからユニークな探して文章をグーグル後)私は強く容疑者捜査のビットを行っているとHERE


編集:2017年7月26日

したがって、この問題を解決する最後の記事として、SamGibsonの詳細な回答に従って、アドレスの上位ビットを設定して、開始ビットの最後のグリッチをマスクするという修正を実装しました。

これは主に期待通りにデータを処理することで機能しましたが、書き込み後の最初の読み取りコマンドで(i2cビットのグループの正しい用語である場合)、スレーブは1ビット早く(書き込みビットの位置)。スレーブがSDAラインと直列に小さな(47オーム)抵抗を追加することでラインをプルダウンしていることがわかります。

私は通常、これを新しい質問として開始しますが、上記のトラブルシューティングで効果がなかった同じスコープをアタッチすると、この問題は解消されるようです。スコーププローブをアタッチしても、これは実際には境界線の問題のようです。スコープに接続しなくても問題は解決されるので、容量の問題だと思います。

スコープが接続されていない問題のプロット

スコープなしのプロット

スコーププローブが接続されているが、接続されていない問題のプロット。スレーブがACKビットではなく書き込みビットをプルダウンすると、電圧がわずかに高くなります。

スコープ付き


1
スコープのトレースはありますか
Kevin White

1
誤ってクロック信号を反転させましたか?
アンディaka

6
I2Cバスに共通の接地線(MSPからI2Cセンサーへ)があり、使用していることを確認します。3本のワイヤが必要:SDA、SCL、およびGND。プルアップ抵抗によってSDAとSCLがVcc(4番目のワイヤの可能性あり)にプルアップされています。
Chris Knudsen 2017

1
@Hugoagogo-いいね!SDAとSCLの両方が異なる方法で異常。私が想定していることトレースが新しいとある失敗センサー?もしそうなら、あなたは古いとトレースを供給することができ、作業センサー?おそらく、その違いはそれほど大きくない可能性があります。つまり、以前に問題がありましたが、それは単に機能していました。より多くの背景情報により、有用なデータが明らかになる可能性があります。たとえば、チップが「不明」であることを考慮して、これらが「新しい」I2Cチップであることをどのようにして知っていますか?MSP430(ユーザーが制御する?)をセンサー(ユーザーが制御しない?)で使用できるようにするために、リバースエンジニアリングが行われたと思います。「元の」構成とはどのように異なりますか?
SamGibson 2017

1
さて、私はサムギブソンに同意します。スパイクは測定誤差であると私は言ってそれほど速くありません。測定セットアップからのものであるか、それらが存在する理由を見つける場合は、さらに調査してそれらを排除するように努める必要があると思います。結局のところ、それらはSCLの立ち下がりエッジに揃えられているようです。また、PCBに直接センサーを接続してみます。これは、問題がケーブルまたはメインボードからのセンサーの距離によって引き起こされていることを除外するのに役立ちます。
ニッカギアン2017

回答:


11

私は答えを見つけたと思います。これは既知の問題であることが判明しましたが、問題がどこにあるのかを決定し、それを検索した後にのみ、私はそれを見つけました!

ここに私が行ったプロセスがありますので、それに従ってください(そして、必要に応じて、私の仮定とは異なる結果が表示された場合は、調査を適応させることができます)。要するにMSP430I²Cの動作と、I²Cスレーブであると疑われるデバイス(IDT ZSC31014)が必要とするI²Cの動作との間には、互換性がないように見えます。そのデバイスのデータシートを用意することは、これを理解するために重要です。

良いニュースは、この問題には(少なくとも)2つの回避策があることです。これについては、最後に説明します。

プロットが厚くなり、別のオシロスコープを接続しても回路が正しく機能しないように見え、唯一の違いはACKが送信されていないことです。

新しいトレースは役立つと思いますが、私はそれらを少し異なって解釈しています。

(最初のトレースで私に関係していたSCL信号のアンダーシュートはまだ最新のトレースにあります。特に、SCL信号のアンダーシュートがSDAのアンダーシュートよりも大きいように見えるのは興味深いことです。最新のトレースです。最終的にはSCLのアンダーシュートを調査することをお勧めしますが、それが主な問題に関連しているとは思いません。)

SDAには次の2つの「グリッチ」があります。

  • スレーブがACKを実行できるようにI²CマスターがSDAの制御を解放し、マスターがSDAを再度駆動する場合、ACKパルスの直前または直後のグリッチは珍しくありません。したがって、私はそれを無視しています。

  • これは、よりまれな最初のSCLパルスの前の初期 SDAグリッチです。その初期のSDAグリッチの振幅(後で参照)と、最初のSCLパルス(0とラベル付けされた)の前にのみ発生するという事実から、SDAのグリッチを確認できる後のSCLパルスの前には発生しません(SCLなど) 4、5、6、または7のラベルが付けられたパルス)、それは測定アーティファクトでも、SCLからのカップリングでもないことがわかります(たとえば)。

(後で参照するために、初期のSDAグリッチは最新のトレースで少なくとも 2Vのよう見えるため、以前のコメントのVddが3.6Vであると、SDAグリッチの振幅は少なくとも(2 / 3.6)= 0.55 x Vddになります。後で説明する関連するI2Cロジックレベルのしきい値)

ACKの違いを無視して、2番目のスクリーンショットで2つのトレースセットの間に別の違いがあると思います。初期の SDAグリッチの振幅はわずかに異なっているように見え、ラベルが付いた一番上のSDAトレースC1(黄色がかった?)とラベルが付いた2番目のSDAトレースM3(青)を比較しています。以下で説明するように、私は今、その初期のSDAグリッチの振幅の違いが問題を表示または非表示にする原因であると考えています。

特にグリッチに関するさらに多くの解決策が役立ちます(これは、「リモートで」問題に取り組みたい場合の問題の1つです-「スコープを自分で操作することはできません!」ズームインすると、それ以外は通常のI²Cロジック「1」の開始のように見える(つまり、特にプルアップを一時的に弱くした場合など、立ち上がりエッジのRCカーブ) tが再び論理「0」に駆動される前に、完全な正電圧に到達します。これは、後でリンクされる別のWebページに表示されるものです。グリッチの形状が異なる場合は、後で行う分析が適用されない可能性があります。

I²Cマスターは、グリッチが発生した時点で、I²Cスタートと最初のSCLクロックパルス(MSbitですが「0」というラベルが付けられています)の間でバスを制御しています。そのため、MSP430の動作は疑わしくなりましたが、その時点ではSCLが低いので、SDAのグリッチ I²C準拠のデバイスに影響を与えることはありません。

それで、そのI²Cスレーブは本当に I²C準拠ですか?結局のところ、MSC430がグリッチを生成していると私が信じているまさにその時、ZSC31014は他のいくつかのI²Cデバイスよりも「うるさい」もので、許容度が低くなっています。

ZSC31014データシートは、デバイスのI²C行動を認めるリスト3つの領域は、「異なる」です。また、このリストの最初の2つの影響を受ける場合もあります(これはこの分析の一部ではありません)が、これは、初期のSDAグリッチに関連して、以下で赤でマークした3番目のポイントです。


ZSC31014データシートから抽出


初期のSDAグリッチの振幅は重要です。グリッチが十分に立ち上がらず、ZSC31014が論理「1」として認識してから再び立ち下がる場合、問題はありません。デバイスはSDAの立ち下がりエッジを見て、その「ルール」を破る必要があります。すでに論理「1」として認識されている場合は、立ち下がりエッジ。

SDA信号のスコープまたはロジックアナライザーの追加負荷など、SDAグリッチの振幅に影響を与えるものはすべて、グリッチがZSC31014によって論理「1」に達したために認識されず、「落下」しないようにするには十分かもしれません。リストの3番目のポイントであるSDAエッジ」が発生する可能性があります(電圧、温度などに応じて、良い日に)。ただし、ご存知のように、オシロスコープの違いは、問題を停止するのに十分な負荷を加えるオシロスコープもあれば、そうでないオシロスコープあります。この設定は非常に重要です。

これにより、以前の「正常に機能している」センサーのバッチが「正常に機能する」だけである可能性があるという私の懸念が確認されました。これらの「正常に機能している」セットアップのMSP430 MCUもSDAグリッチを生成する可能性が高いためです。レポートしたさまざまな動作を説明する可能性のあるセンサーのバッチ間の可能な違いについての私の理論(「機能する」バッチと「機能しない」バッチ)を次に説明します。

興味深いことに、ZSC31014は、メーカーのリストに記載されていない別の領域の標準I²Cとは異なります。これにより、センサーのバッチ間で違いが見られる理由を説明できる可能性があります。

標準のI²Cロジックしきい値は(簡略化されています)-I²C仕様に示されているように、ロジック "0"の場合は0.3 x Vdd未満、ロジック "1"の場合は0.7 x Vddを超えます


I2C仕様からのロジックレベルしきい値


ただし、ZSC31014には、0.2 x Vddと0.8 x Vddという異なるしきい値があります。つまり、これらのしきい値の間の「未定義領域」は、一般的なI²Cデバイスより大きくなります。


ZSC31014データシートのロジックレベルしきい値


その「未定義領域」大きいと、グリッチが未定義の電圧レベル領域に入る可能性が高くなり、論理「1」として認識される可能性あります(0.2 x Vddを超えるものはZSC31014によって論理「1」として認識される可能性があります) 、未定義の領域では何でも許可されるため、論理「1」として認識される必要がある場合、0.8 x Vddを超えます。また、前に説明したように、グリッチが論理「1」に達したとZSC31014が認識した場合、再び論理「0」に落ちると、必要なI²C動作のために赤でマークされた「ルール」を破っています。 ZSC31014による。

その「未定義」電圧領域での論理レベルの認識は指定されていないため、センサー製造元は、0.7 x Vddに達したときにのみ論理「1」を認識する1つのバッチを作成し、それを認識する別のバッチを作成しても、仕様に違反していません。たとえば、0.4 x Vddのような低い論理「1」。その架空の2番目のバッチは、SDAのグリッチをリストの3番目のポイントに違反してSDAの立ち下がりエッジと見なす可能性が高くなりますが、仕様に違反していません。

(私が長年にわたって取り組んできた問題の多くは、次のようになっています。2つのデバイスがあり、どちらも個別に抜け穴のある仕様を破っていませんが、1つは煩雑で許容範囲が狭く、他の1つは動作不明瞭であるため、接続されたデバイスの耐性を高める必要があります!これら2つのデバイスはそれぞれ、他のデバイスの大部分と良好にインターフェイスしますが、相互に接続されている場合は信頼できません(または完全に失敗します)。

それで、あなたは何ができますか?私は2つのオプションを考えました:

  • MSP430を使用しないでください-その初期のSDAグリッチを作成しない別のMCUを使用してください。ただし、ソフトウェアに多くの時間を費やしていて、コードを別のMCUに移植したくない場合は、それを回避できると思います。

  • 内蔵のI²Cハードウェアモジュールを使用する代わりに、MSP430のI²Cプロトコルを「ビットバン」します。このようにして、I²C信号を完全に制御し、グリッチの発生を防ぐことができます。ただし、独自のI²Cルーチンを作成してデバッグするのは明らかに手間がかかり、結果のコードはMSP430I²Cハードウェアモジュールを使用する場合よりも大きくなる可能性があります。これは、フラッシュスペースが不足している場合に問題になる可能性があります。

次に、MSP430I²Cの問題を検索しましたが、MSP430からの初期のSDAグリッチが原因で、MSP430 + ZSC31014のこの組み合わせが既知の問題であることがわかりました。TI E2E MSP430フォーラムでこのスレッドを参照してください。

TI E2Eフォーラム:MSP430 I2Cグリッチパルスが原因でI2C周辺機器チップに問題が発生する

そこで言及されている回避策は、ZSC31014I²Cアドレスを変更して、正のグリッチ発生する可能性があるときにSDAが高くなるようにすることです。SDAが高くなるのでとにかく、SDAに実際のグリッチはありません。

私たちの回避策は、ビット6が設定されたアドレスを持つようにZSCチップを構成することです(たとえば、現在0x42を使用しています)。これにより、グリッチパルスがアドレスビット6の持続時間のきれいな「高」ビットになり、削除されます問題のある立ち下がりエッジの。

同じ回避策は、事実上、ZSC31014データシートの提案の逆で、マークした赤いボックスにあります。彼らは、ZSC31014I²Cアドレスの最初のビット(MSbit)が0の場合、SDAグリッチを防止する必要があると言っています。I²CアドレスのMSbitを「0」にせず、「1」にしてください。 7ビットI²Cアドレスのビット6を設定してください!

そのTI E2EフォーラムスレッドとZSC31014データシートはどちらもI²Cアドレスに重点を置いているため、バス上の他のデータの送信中にSDAグリッチが発生しないか、発生しても問題にならない可能性があります。あなたはそれを調査する必要があります。

したがって、別のMCUを使用する最初の回避策を無視して、2つの(より実用的な)回避策は次のいずれかです。

  • 独自のコードを作成してMSP430I²Cバスをビットバンギングし、SDAでグリッチを作成しないようにする、または
  • ZSC31014I²Cアドレスを変更して、7ビットアドレスのビット6が設定されるようにします。つまり、グリッチが発生したときにSDAがすでにハイになっているため、ZSC31014がアドレス指定されたときにSDAで実際のグリッチは発生しません(SDAグリッチがデータ転送中に他のI²C開始イベントの後に発生しない、または発生した場合、ZSC31014が「混乱」しないこと)。

お役に立てば幸いです。


2
これは素晴らしく、非常に役立つ回答です。承認済みとマークする前に、トラブルシューティングを通じてそれを続けるための担当者を増やすことができる方法はありますか。また、問題が発生した場合は、回避策を使用して質問を更新します。
Hugoagogo 2017

1
@Hugo -非常に親切な思考だ:-)私はそれを提供することによって行うことができると信じて恵みの恩恵理由は、「だろう既存の回答を報酬を」。私はそのプロセスの専門家ではないので、それ以上は言えません。もちろん、私は追加の担当者を迎えることができれば幸いです(分析と書き込みを行うのに数時間かかりました;-))しかし、賞金を使用したくない場合、またはプロセスを理解できない場合、それで心配はありません、とにかくそれはすべてポジティブなカルマです:-)私の答えがうまくいくことを願っています!
SamGibson 2017

@Hugo-回答の更新が通知されるかどうかはわかりませんが、参考までに、SCLとそのアンダーシュートに関する段落を追加しました(まだパズルですが、主な問題に関連しているとは思えません)。最新のスコープトレースの「初期SDAグリッチ」の振幅が少なくとも0.55 x Vddであると推定しました。これは、さまざまなセンサー(またはセンサーのさまざまなバッチ ;-)が処理できる「未定義」の電圧領域に十分入る仕様を壊すことなく、論理「1」かそうでないか。しばらくオフラインになるので、また頑張ってね!
SamGibson 2017

1
助けてくれて
ありがとうござい

質問の最後の更新を検討してもらいますか。
Hugoagogo 2017
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.