llce CANの使用中に問題が発生しました。接続しているCANデバイスが再起動したり、物理的に再接続したりすることがあり、その結果、バス上の終端抵抗が減少してしまいます。その結果、実行中のプログラムがACKエラーを継続的に発生し、異常動作を引き起こしていました。上記の問題を解決する方法があれば教えていただけますか？ LLCE CANドライバの関連ファイルを提供していただけますか？
こんにちは、 @JACK_Q
ご投稿ありがとうございます。
さらに詳しい情報を教えていただけますか?
1. RDB2 またはカスタム ボードが使用されていますか?
2. すべての LLCE-CAN インターフェースがこのような問題に対応しますか、それとも特定のチャネルのみですか?
3. あなたのCASEでは、どのバージョンの RTD および LLCE ソフトウェアが使用されていますか?
4. 問題は、カスタム ソフトウェアでのみ再現できますか。それとも、NXP が提供したサンプルでも発生する可能性がありますか?
また、LLCE CANのドライバソースを見つけたい場合は、NXPアカウントから見つけるか、リンクから適用することができます。
BR
チェイン
こんにちは、 @JACK_Q
ご返信ありがとうございます。
A53 コアで Vxworks を使用していて、これらの M7 コア ベースのデモ コードを Vxworks に移植しているのだと思います。
残念ながら、M7 デモは RTD に基づいており、スタブ関数は通常 AUTOSAR で実際に実装する必要があるため、vxworks の正式なサポートはありません。ソフトウェアの観点から互換性のない部分があり、自分で実装する必要がある場合があります。
BR
チェイン
ご返信よろしくお願いします。
最初はハードウェアとして RDB2 ボードを使用し、ソフトウェアは図 1 に示すとおりでした。S32DS3.5上でも異常なく動作し、対向CANデバイスとの接続が切断された状態でも動作に異常はありませんでした。
図1
その後、ソフトウェアが VxWorks 上で動作するように修正され、ハードウェアがカスタムマザーボードになったところ、反対側のデバイスが切断されるという問題が発生しました。ファームウェアがエラーを検出すると、通知 (ackerr) を継続的に報告します。結局、ソフトウェアは異常終了しました。
提供されているサンプル プロジェクト Can_Llce_DS_Loopback_S32G274A_M7 で同様の問題の解決策を探そうとしましたが、プロジェクトには ackerr 問題に対する具体的な解決策がないことがわかりました。上位層にエラーを通知するためのインターフェースを残して、スタブ関数のみが記述されているように見えました。
図2
LLCE1_0_9 で ACK 例外がどのように処理されるかを知りたいです。こうすることで、同じソリューションを自分の VxWorks システムにもCAN適用できるかどうかを確認できます。
ご返信よろしくお願いします。
LLCE1_0_9 の「LLCE_firmware_user_guide.pdf」で LLCE CAN レジスタ SR を確認しました。
この図は、SR の 8 番目のビットが、アッカーが発生したかどうかを示すために使用されていることを示しています。ackerr の問題を処理するためのコマンドがいくつかあるはずですが、ドキュメントには詳しい情報が見つかりませんでした。さらに詳しい情報を教えていただけますか?私の最終的な目標は、RTD が ackerr 問題をどのように解決するかを理解し、それを参照して自分の環境でこの問題を解決することです。
こんにちは、 @JACK_Q
ご返信ありがとうございます。
私の理解では、あなたが言及した ACKERR はBCAN プロトコル エラーです。これは情報提供を目的としており、LLCE ソフトウェアの問題を示すものではなく、デバッグ目的で存在します。場合によっては、出力をあふれさせて他の重大なエラーを隠さないように、これらを無効にすることをお勧めします。
一部の実装ではコントローラ統計情報にのみ記録されることを覚えています。それを参照するか、カスタム要件に応じて独自の方法を実装することができます。
BR
チェイン