RT1064デバイスのI2C2インターフェースはモジュールAに接続されます。通信異常は400kHzで発生しますが、100kHzでは正常に動作します
1. 同じシリーズ内の異なるモデルのモジュールBを400kHzで接続することは問題ありません
2. 波形の観点からは、ホストクロックが伸縮され、モジュールAに接続された後に復元される異常に相当します
追伸:デバイスのI2Cドライバーポートを別の1064デバイスに実装し、モジュールAをテストしましたが、400kで問題ありません
その理由は何でしょうか?
1. 図1 モジュールA ロジックアナライザの400kHzにおける異常波形
2. 図2：モジュールAの100kHzにおけるロジックアナライザの波形
3. 図3：モジュールBの400kHzにおける波形
こんにちは、 @foreverwlh2025 さん。
あなたの観察からすると、問題はモジュールA自体の異常というよりも、2段ADUM1251アイソレーションリンクによる400 kHz I2Cのタイミングマージン不足に関連している可能性が高いようです。
ライズ時間が規格内であっても、RT1064ではLPI2Cマスター側の400kHz構成、特にMCFGR2[FILTSCL/FILTSDA]およびMCCR0/MCCR1の確認を推奨します。なぜなら、RT1064のマスター同期レイテンシはライズ時間だけでなく、デジタルフィルターやタイミングパラメータ設定にも影響を受けるからです。
プロジェクトで実際に使用されている構成を読み、RT1064リファレンスマニュアル第47章の表47-5「LPI2C例タイミング構成」と比較することをお勧めします。
特に、選択したクロック条件における以下の設定が、サンプル値と一致しているかどうかを確認してください。
- I2Cモジュールクロックソース
- 目標ボーレート：400Kbps
- PRESCALE
- FILTSCL / FILTSDA
- セソルド
- クロックロ
- CLKHI
- データビデオ
お役に立てれば幸いです。
よろしくお願いいたします。
5月
追加情報として、昨日ポジショニングにいくつかの進展がありました:
ハードウェア拡張は以下の通りです:
マザーボード:RT1064--- ADUM1251 3.3V～5V
サブボード：ADUM1251 - モジュールA 5V～3.3V
検証の結果、ハードウェアリンクの2層にADUM1251を追加した後、モジュールAで通信異常が発生したことが判明した。しかし、ADUM1251を取り外すと、400kで通信が正常に戻った。その理由は何でしょうか?
追伸:ハードウェアエンジニアは、ADUM1251は通信レイテンシを増加させるだけで、それ以外には影響がないと考えています
当社の製品はまもなくリリースされ、数日間この問題を調査してきました。できるだけ早くご返信いただければ、大変ありがたいです!
ハイ
補足情報
1.2人のハードウェアエンジニアはオシロスコープで問題の波形を確認し、上昇時間は100+ns以内の要件を満たしました
2. I2Cの初期化および読み書き機能ドライバを別のタイプのRT1064デバイスに移植し、モジュールAを問題なくテストしました
以下の図は、別のデバイスモジュールAの波形を示しています。テスト用ロジックアナライザー
疑い：
1.ストレッチ後に時計が異常に回復するなら、他にどんな理由が考えられますか
2. 前回の返信で言及されたMCFGR2のような設定設定専用機能はありますか?I2C初期化プロセスで設定するインターフェースは見当たりませんでした
----上昇時間が満たされた場合、これらのレジスタ設定を考慮する必要はないのでしょうか?
こんにちは、 @foreverwlh2025 さん、
私たちの製品にご関心を寄せ、コミュニティをご利用いただき、本当にありがとうございます。
これはモジュールAの問題ではなく、その特定のRT1064 LPI2C2バスの400 kHzのタイミングマージンの問題だと思います。
RT1064では、LPI2Cのタイミングはバスの上昇時間、バス負荷、プルアップ抵抗、グリッチフィルタ レイテンシの影響を受けます。
リファレンス・マニュアルRT1064RMでは、上昇時間が長いと同期レイテンシが増加すると説明されています。（第47.3.1.4章を参照）タイミングパラメータ）
マスターグリッチフィルターMCFGR2[FILTSCL/FILTSDA]は、**レイテンシ**がSCLの最低ロー/ハイ期間を下回るように設定されなければならず、RT1064はMCCR0/MCCR1の400 kbpsタイミング設定の例を提供しています。表47-5をご確認ください。LPI2Cのタイミング構成例
したがって、モジュールAがバスエッジをわずかに遅くしたり、実効負荷を変えたりすると、バスは400kHzで故障しても100kHzでは動作し続けることがあります。
お役に立てれば幸いです。
よろしくお願いいたします。
5月
10 MHzのLPI2C機能クロックは、RT1064リファレンスマニュアルの400 kbpsのタイミング設定例には記載されていません。
このクロックを使用すれば400kbpsのボーレートを生成することは可能ですが、自動生成されるタイミングパラメータは、特にtLOW、tHIGH、セットアップ/ホールドタイミング、およびデータ有効タイミングに関して、I2C仕様と照らし合わせて慎重に検証する必要があります。
デザインリスクを減らすために、リファレンス・マニュアルに示されている48 MHzなどの検証済みクロックソースを使用することが推奨されています。
以下は印刷設定です。どのパラメータを調整する必要があるでしょうか？
追伸:どうやら自動インターフェース割り当てによるようです
60MHzと8MHzの両方を変更してみましたが、それでもうまくいきませんでした。下図の赤い枠で囲まれた部分は、修正後に印刷された値を示しており、マニュアルに記載されている値とは異なっています。
こんにちは、 @foreverwlh2025 さん。
I2Cクロックを設定する方法はいくつかあります。
提案として、8 MHzと60 MHzを試してみるのも良いでしょう。この2つのクロック設定は比較的簡単に達成できます。
SDKのデモを使っています:
「evkmimxrt1064_lpi2c_edma_b2b_transfer_master」
方法1：LPI2Cクロックソースを60MHzに設定する
時計の分周器を0に設定するだけです。
方法2：LPI2Cクロックソースを8MHzに設定する
MCUXpresso IDEsクロックツールを使い、以下の通りに設定してください。クロックソースとしてOSC_CLKを選択し、分周器を3に設定すると、LPI2C（I2C）モジュール用の8MHzクロックが生成されます。
お役に立てれば幸いです。
よろしくお願いいたします。
5月
現在のI2Cクロックは、SDK2_13_0-EVK-MIMXRT1064 \ ボード \ evkmimxrt1064 \ river_deamples \ lpi2cディレクトリ内のサンプル構成に基づいて構成されています。
#define LPI2C_CLOCK_SELECT(0U)
#define LPI2C_CLOCK_DIVIDER(5U)
CLOCK_SetMux(kCLOCK_Lpi2cMux、LPI2C_CLOCK_SELECT);
CLOCK_SetDiv(kCLOCK_Lpi2cDiv、LPI2C_CLOCK_DIVIDER);
---正確な8MHzか48MHzをどうやって修正すればいいですか?（時計の木が見えないようですね）
こんにちは、 @foreverwlh2025 さん。
例えば、60 MHzのI2Cクロックを使用する場合、以下の構成を適用できます。
お役に立てれば幸いです。
よろしくお願いいたします。
5月
図に示すように、パラメータに対応するようにレジスタ設定を変更しようとしましたが、60MHzでは改善がありませんでした。良いモジュールでも8MHzでは正常に動作しません
しかし、私たちが使っているアイソレータチップはSCLの双方向に対応していません。アイソレーターチップを交換した後、
検査結果は正常だった。この注文は閉じていけます