I2C通信できない原因と確認方法｜配線・アドレス・ACKを順番に確認

症状から原因を絞る：I2Cが応答しないときの見分け方

「デバイスが見つからない」という表示だけでは、故障箇所は特定できません。まず通信していない時間のSDAとSCLを測ります。両方が安定してHighなら、少なくともアイドル時の線は解放されています。片方または両方がLowのままなら、短絡、誤配線、デバイスの電源断、バスを保持している別デバイスなどを疑います。測定時はプローブのGNDを適切に取り、信号線を不用意に短絡させないようにしてください。

線がアイドル状態に戻っているのにアドレス後のACKがない場合は、アドレス形式、アドレスピン、電源投入後の待ち時間、バス上のデバイス選択を順番に見直します。アドレスには応答するが読み出し値が違う場合は、レジスタ番号の幅、送信順、Repeated START、読み出しタイミング、データシートの初期化条件が次の確認対象です。症状を「アイドル」「アドレスACK」「レジスタ読み出し」の段階に分けると、関係のない設定を変更せずに済みます。

複数のデバイスが同じバスにつながっている場合、1台ずつ切り離せる評価環境なら、構成を変えたときに症状がどう変わるか記録します。I2Cマルチプレクサがある場合は、選択レジスタの設定とチャネルを確認してください。原因を探すために電源を入れたままコネクターを抜き差しするのは避け、ボードの手順に従って電源を落としてから構成を変えます。

プルアップ抵抗と立ち上がり時間を確認する

I2CのHighは、通常、デバイスが線を強く駆動して作るのではなく、プルアップ抵抗によって線を電源側へ戻すことで得られます。抵抗がない、抵抗値が大きすぎる、バス容量が大きいと、立ち上がりが遅くなり、設定した通信速度でHighとして判定されないことがあります。反対に抵抗値が小さすぎると、Lowを駆動するデバイスに過大な電流が流れるおそれがあります。

複数のモジュールにプルアップ抵抗が実装されていると、並列接続によって合成抵抗が小さくなります。例えば同じ抵抗値が2本並列なら合成値はおよそ半分です。モジュールを追加した後だけ通信が不安定になる場合は、回路図と実装を確認し、抵抗値を単純に足し算しないでください。設計値は電源電圧、入力容量、配線を含むバス容量、許容立ち上がり時間、デバイスのシンク電流を使って見積もります。

オシロスコープでは、High電圧だけでなく立ち上がりの形と時間も観察します。測定プローブの容量自体がバスに影響する場合があるため、プローブ設定と測定条件も記録してください。SDA/SCLを観察するロジックアナライザーはデコードに便利ですが、アナログ波形の品質や電圧マージンを判断する代わりにはなりません。必要に応じて両方の測定器を使い分けます。

ロジックアナライザーでSTART・アドレス・ACKを読む

測定前に、対象バスの電圧に対応した入力であること、基準GNDが共通であること、サンプル速度が通信の時間幅を十分に捉えられることを確認します。キャプチャを始めたら、START条件の後にどのビット列が送られ、9番目のクロックで受信側がACKまたはNACKを返したかを見ます。デコーダー画面のアドレス表示だけで判断せず、ツールが7ビット表記か8ビット表記かも確認します。

アドレスの後にACKが見えるのに、その後でNACKになるなら、デバイス自体は選択できていても、次のレジスタ番号やデータ長が期待と違う可能性があります。読み出しでは、ホストがレジスタ番号を書いたあとにRepeated STARTを出すデバイスもあれば、STOPを挟む手順を要求するデバイスもあります。プロトコルデコーダーの表示とデータシートのタイミング図を同じ順序で照合し、推測でトランザクションを組み替えないことが大切です。

キャプチャには、バス速度、電源電圧、接続したデバイス、測定点、再現した操作をメモします。波形画像だけを保存するより、再現条件と一緒に保存すると、後日ドライバー変更や基板改版の前後を比較できます。第三者へ共有する場合は、製品情報や機密データが写り込んでいないかも確認しましょう。

よくある質問：アドレス表記とバススキャン

データシートに書かれたアドレス値をホストAPIへそのまま渡せるとは限りません。多くのAPIはR/Wビットを含まない7ビットアドレスを受け取り、送信時に方向ビットを付加します。一方、資料には読み出し用・書き込み用の8ビット値が載っていることがあります。APIの仕様とデータシートの表記を確認し、どのビットがアドレスでどのビットが方向かを分けてください。10ビットアドレスを使うデバイスでは、ホストとドライバーがその形式をサポートしているかも必要です。

バススキャンは、全アドレスに対して応答を問い合わせる診断方法です。しかし、すべてのデバイスで無条件に安全とは限りません。特定のアドレスへの問い合わせが状態を変えるデバイスや、スキャンを想定していない実装もあります。対象製品の仕様と使用するツールの動作を確認し、まず評価用の安全な環境で実施してください。LinuxのI2Cデバイス情報を調べる場合も、デバイスツリーやドライバーが管理するバスに対して、競合するユーザー空間操作を行わないようにします。

クロックストレッチやバス回復が関係する場合、ホストコントローラーごとに対応状況や制約が異なります。SCLを強制的に切り替える回復手順を試す前に、デバイスの電源状態とデータシートの回復方法を確認してください。安全性が確認できないときは、製品の評価手順やメーカー資料を優先します。

再現可能なI2Cデバッグ記録を残す

調査を再開したときに同じ条件を作れるよう、ボード名とリビジョン、接続デバイス、電源電圧、I2C速度、ホスト側ドライバー、実行した操作を記録します。症状は「認識しない」だけでなく、例えば「電源投入後、SDAはHigh、SCLはHigh、アドレス送信後にNACK」のように観測した段階で書きます。測定器の型番、プローブ位置、アナライザーのデコード設定も残せば、別の担当者が同じ波形を確認できます。

設定変更を行ったら、変更前の値と変更後の値を併記し、元に戻せるようにします。プルアップ抵抗の変更やバス速度の低下で症状が改善した場合も、それだけで恒久対策と決めず、温度、電源条件、バス上の全デバイスを含む動作範囲を確認します。速度を下げることは切り分けに役立ちますが、製品仕様が要求する速度を満たすか別途検証が必要です。

不具合報告には、成功する条件と失敗する条件を一つずつ添えます。例えば、同じデバイスを短い配線で単独接続した場合と、製品相当の配線長で全デバイスを接続した場合を比較します。差が分かれば、アドレス設定、配線容量、プルアップ、電源、他のデバイスによるバス占有など、調べる範囲を具体化できます。測定記録には推測と観測事実を分けて書くと、後から誤った前提を引き継ぎにくくなります。

最終的に解決したら、原因だけでなく再発防止策も記録します。回路設計の修正、初期化順序、ドライバー設定、製造検査のいずれが対策になるかを検討し、関連するテストや設計資料へ反映します。個別ボードでの一度の成功を、すべてのI2Cデバイスに通用する一般則として扱わないことが重要です。

I2C通信できないときの確認例

新しく接続したセンサーがホストから見つからない例を考えます。まず電源を切り、センサーの型番と基板リビジョンを確認し、回路図で電源、GND、SDA、SCLの端子を特定します。ロジック電圧がホストと適合すること、アドレス選択ピンが想定どおりであることをデータシートと照合します。ここで不一致が見つかったら、通電してスキャンする前に配線や部品構成を直します。

次に通電してアイドル電圧を測り、SDAとSCLがHighへ戻っていることを確認します。片方がLowのままなら、信号の短絡、デバイスの電源、バスを保持している相手を調べます。両線が正常なら、対象デバイスの起動待ち条件とホストAPIのアドレス形式を確認します。バススキャンを使うときは、そのデバイスとドライバーで安全かを調べ、結果を7ビットアドレスとしてデータシートと比較します。

アドレスを指定した読み書きを行う場合は、最初のアドレスバイト、ACK/NACK、レジスタ番号、読み出し方向、Repeated START、STOPの順をキャプチャします。アドレスにACKがあり、レジスタ番号でNACKになるなら、アドレスを何度も変えるのではなく、レジスタ幅や初期化手順を確認します。波形が取れない場合は、測定器のGND、入力電圧範囲、トリガー条件、サンプル速度を見直し、別の測定手段で信号の有無を確かめます。

一つ修正したら同じ操作で再試験し、成功した条件と失敗した条件を記録します。バス速度を下げた場合に通信が改善したとしても、配線や抵抗の設計が適切になった証拠とは限りません。最終的な動作速度、温度や電源変動を含む範囲、他のバスデバイスとの共存を確認し、製品要件を満たしているか判断してください。量産や長期運用で使う場合は、起動直後だけでなく連続アクセスや電源再投入後の再現性も確認し、必要な監視ログと異常時の復旧方法を設計資料へ残します。

I2Cデバイスが認識されない場合の実践的な切り分け例

新しいI2Cセンサーを評価ボードへ追加したのに、アプリケーションの一覧へ現れない状況を考えます。最初に「認識されない」を、電源が入らない、バスがアイドルに戻らない、アドレスにACKがない、読み出し値が不正、のように観測できる状態へ分けます。現象が起きた操作と時刻も記録し、起動時だけなのか、繰り返しアクセスでも起きるのかを区別してください。

次に電源を切り、センサーの型番と基板リビジョンを確認して、回路図上のSDA、SCL、GND、電源端子を実物へ対応付けます。アドレス選択ピン、必要な電源電圧、起動後の待ち時間、ホスト端子の耐圧をデータシートと照合します。コネクターの向きやシルク印刷だけで判断せず、端子番号と信号方向を追ってから再通電してください。

通電後は通信を始める前のSDAとSCLを測り、仕様上のHighレベルへ戻っているか確認します。片方がLowなら、アドレスを変える前に短絡、配線違い、電源不足、接続デバイスによるバス保持を調べます。両方が正常なら、ホストのI2Cコントローラーが対象ピンへ割り当てられているか、別機能と競合していないかをボード資料で確認します。

最後に対象デバイスだけを接続した最小構成で、データシートに記載されたアドレスと一回のアクセスを試します。バススキャンを使う場合は、そのデバイスへの問い合わせが安全かを確かめ、検出結果のアドレス表記もAPIの仕様と照合します。測定値、実行コマンド、波形、変更点を一緒に残せば、他のデバイスを戻したときに差分を追いやすくなります。

I2CのACK後に読み出しが失敗するときの確認順

アドレス直後にACKが確認できても、センサーの読み出し全体が成功したとは限りません。プロトコルを、アドレス送信、レジスタ番号送信、方向切り替え、データ受信、終了条件に分け、どの段階でNACKや予期しない値が出るか記録します。デコーダーの最終的な成功表示だけでなく、各バイトの順番とACK/NACKを確認するのが出発点です。

データシートでレジスタのアドレス幅を調べます。レジスタ番号が1バイトとは限らず、上位バイトから送る形式や、ページ選択レジスタを先に変更する形式もあります。ホストAPIがレジスタ番号を自動送信する関数なのか、任意のバイト列を送る関数なのかも確認してください。同じ番号を二重に送ったり必要なバイトを省いたりすると、アドレスに応答しても目的の値を読めません。

読み出し前にRepeated STARTを使うかSTOPを挟むか、データシートのタイミング図で確認します。デバイスによっては変換完了までの待ち時間、初期化コマンド、読み出し可能状態の確認が必要です。値が常にゼロ、前回値のまま、または毎回異なる場合は症状を記録し、リセット直後と初期化後の波形を比較します。

複数バイトを数値へ変換する処理も、バス通信とは分けて検証します。ビッグエンディアン／リトルエンディアン、符号付き形式、予約ビット、単位、固定小数点の倍率はデータシートに従います。既知のテスト値や識別レジスタを先に読めるなら、通信の成否とアプリケーション側の換算処理を混同せずに済みます。

I2Cバスの配線とプルアップ抵抗を見直す手順

配線確認では、回路図のネット名、コネクターの端子番号、基板上の実装を一つずつ対応させます。SDAとSCLの入れ違いだけでなく、同じコネクターに並ぶ電源や割り込み端子の誤接続にも注意します。通電前に導通を確認し、抵抗測定を行うときは回路への給電がないことを確かめてください。

プルアップ抵抗の見直しでは、ホスト基板と各モジュールに実装された抵抗をすべて一覧にします。同じ電源へ接続された抵抗は並列になるため、モジュール追加によって合成抵抗が下がる場合があります。値を変える前に信号電圧、デバイスの許容シンク電流、バス容量、要求速度を整理し、設計条件をデータシートと仕様書から確認します。

オシロスコープで立ち上がりを調べる際は、測定点とプローブ条件を固定して比較します。長い配線、分岐、コネクター、測定プローブはバス容量に影響するため、センサー単体の短い配線で成功しても製品相当の構成では失敗することがあります。短い既知の配線で基準波形を取り、配線やデバイスを一つずつ戻すと影響箇所を見つけやすくなります。

通信速度を下げて改善する場合は、速度と波形を切り分け結果として記録します。それだけで抵抗設計や配線品質が適切だと結論付けず、製品が必要とする速度で温度、電源、接続台数の条件を満たすか改めて評価してください。変更した抵抗値、実装位置、速度、ボード版を設計記録へ反映し、同じ構成を再現できるようにします。

I2Cの調査結果を再現できる形でまとめる

不具合報告には期待した動作と実際の観測を分けて書きます。「通信不良」だけで済ませず、「電源投入後にSDA/SCLはHigh、アドレス送信後にNACK」のように段階を明記します。アドレス値を記すときは、公開可能な範囲で7ビット表記か8ビット表記かも添え、データシートとホストAPIのどちらを参照した値か分かるようにしてください。

再現手順にはボードと周辺機器の版、電源投入順、初期化操作、I2C速度、実行回数を含めます。正常になる最小構成と失敗する構成の両方があれば、どの部品や配線を戻した時点で症状が変わるか比較できます。設定変更は一度に一項目とし、変更前の値と元に戻す方法も記録してください。

波形を共有するときは測定器の入力条件、時間軸、サンプル速度、トリガー、測定位置が分かる形で保存します。デコーダー画面だけでは電圧品質や立ち上がり時間を判断できないため、必要ならアナログ波形も添えます。画像名に日付や試験条件を含めると、同じ現象の再測定を見分けられます。

修正後は最初に失敗した操作を同条件で繰り返し、連続アクセス、電源再投入、他デバイスとの共存も確認します。解決した条件だけでなく、未確認の速度範囲や環境条件も明確にします。公開する記事や問い合わせには顧客データ、認証情報、未公開の基板情報が含まれないよう確認してください。

I2CセンサーのアドレスNACKを切り分ける具体例

アドレス送信の直後にNACKが出る例では、まず測定器でSTART条件とアドレスの各ビットが見えているかを確認します。波形自体がなければ、ホストコントローラーの有効化、ピン多重化、バス番号、通信開始処理を調べます。波形が見えるなら、ホストが実際に送ったアドレスを読み、設定ファイルに書いた値だけを根拠にしないようにします。

送信値を確認したら、データシートのアドレス表にある固定ビットと選択ピンの状態を照合します。資料に書かれた読み出し用・書き込み用の値が8ビット表記なら、ホストAPIが要求する7ビット形式へ変換する必要があるかもしれません。変換を行うときは、方向ビットを二重に含めていないか、アドレスの上位・下位ビットを取り違えていないかも確認します。

次に電源電圧、GND、起動待ち時間、リセット端子、アドレス選択ピンを見直します。I2Cバス上に複数デバイスがある場合は、可能な評価環境で対象デバイスだけにしたとき結果が変わるか比較してください。電源を入れたままコネクターを抜き差しせず、構成変更はボードの電源を落としてから行います。

一つの仮説を確認したら、同じアドレスと同じバス速度で再測定し、変更前後の波形を保存します。NACKが解消しても、続くレジスタアクセスや読み出しデータが正しいか別に確認します。検出されたという事実と機能が正しいという判断を分けることで、初期化漏れやレジスタ指定ミスを次の段階で追いやすくなります。