NXPのエキスパートの皆様、こんにちは。
現在、S32G3(LINマスターとして動作)でLLCEコンポーネントを使ったLIN実装に取り組んでいます。私たちはS32G_LLCE_1_0_10を使用しています。
LLCE LINファームウェアのフレームタイムアウト構成に関して奇妙な挙動に遭遇しており、ファームウェアのブラックボックスロジックについて内部の詳細や説明を求めたいと思います。
問題の説明:
LINチャネルを「Disable Frame Timeout」がUNCHECK(タイムアウト検出が有効)に設定し、Response Timeout値を14に設定した場合:
LLCE LINマスターはヘッダー(ブレーク+同期+PID)をバスに正常に送信します。
スレーブノードはヘッダーを受信し、正しいデータとチェックサムを即座に返信します。
しかし、LLCEのLINマスターはランダムまたは継続的にデータの取得・受信に失敗します。データがLLCEファームウェアによって失われたり、破棄されたりしたかのように動作します。
回避策が見つかりました:
他のすべてのハードウェアおよび物理バス環境をまったく同じに保ったまま、設定ツールで「フレームタイムアウトを無効にする」(ファームウェアの内部タイムアウトロジックを無効にする)にチェックを入れるだけで次のようになります。
マスターはデータを一切ドロップせず、スレーブからのすべての応答を正常に受信します。
私たちの質問:
LLCE_firmware_user_guide.pdfには内部ステートマシンに関する情報が非常に限られているため、この動作に困惑しています。
LLCEファームウェア内部では、タイムアウト値「14」はどのように正確に計算されるのですか?値14は、特定のGPT/タイマークロックソースに関連する絶対マイクロ秒、ビット時間、またはサイクルを表しますか?
奴隷が即座に返答したにもかかわらず、なぜ主人はその反応を捉えられないのか?タイムアウトカウンターが早すぎる(例えばヘッダーの送信が終わる前)に始まっている可能性はありますか?それとも「14」という閾値が内部ハードウェアやファームウェアのレイテンシのために小さすぎるのでしょうか?
有効な応答を破棄することなくフレームタイムアウト保護を有効にしたままにしたい場合、このタイムアウト値を適切に計算して設定するための推奨される方法はありますか?
LLCE LINファームウェアの内部タイミングロジックに関するドキュメントやアプリケーションノート、洞察があれば大変ありがたいです。
よろしくお願いいたします!
よろしくお願いします、
cjq
こんにちは、 @cjq
ご説明ありがとうございます。
1.DisableFrameTimeoutボックスにチェックを入れると、Linドライバーは最大フレーム長より長いフレームを受け入れます。
2. 「LinResponseTimeout」の場合、リセット値は0Eh = 14で、これはT_Response_Maximum = 1.4 x T_Response_Nominalに対応します。これは1バイトの応答タイムアウト時間(ビット時間)です。
BR
チェイン
こんにちは、チェンインさん
迅速なご対応ありがとうございます。ご質問への回答と、ファームウェアのバージョンに関する訂正事項を以下にご説明いたします。
ハードウェア:弊社では、NXPの公式リファレンスボードではなく、S32G3をベースにしたカスタムボードを使用しています。
実装:公式のサンプルを直接実行しているわけではありません。これは当社独自の実装ですが、NXPの公式サンプルコードを参考に開発されています。
ファームウェアバージョンの訂正:最初の投稿でバージョンに関して間違いがあったことに気づきました。実際にはS32G_LLCE_1_0_10ではなく、S32G_LLCE_1_0_09を使用しています。
バージョン1.0.09のLIN応答タイムアウトに関連する既知のバグや、この特定のファームウェアバージョンでタイムアウト値「14」がどう解釈されるか確認を手伝ってもらえますか?
よろしくお願いいたします、cjq
こんにちは、 @cjq
投稿ありがとうございます。
1. NXPのS32G3ベースのカスタムボード、またはリファレンスボードのどちらをお使いでしょうか?
2. この問題は、お客様独自の実装で発生したものですか、それともNXPが提供するサンプルで発生したものですか?
BR
チェイン