@danielmartynekこんにちは。S32K314のLPUART1をLINスレーブとして使用して通信していたところ、最初はスレーブがホストから送信されたフレームヘッダーに正常に応答できたのですが、しばらくするとスレーブがホストから送信されたフレームヘッダーに応答できなくなってしまいました。さらに、データを受信する際、2回目の割り込み以降は、データ受信ブレークポイントに留まることができなくなりました。下図に示すように、コールバック関数を使用してスレーブマシンの応答と受信を処理します。デバッグ監視機能を使用した際に、初めて割り込みに入ったときに同期間隔セグメントの状態を検出し、同期間隔セグメントを処理する関数に入ることができることがわかりました。しかし、再び割り込みに入ると、(void)Lpuart_Lin_Ip_HwClearStatusFlag(Base, LPUART_LIN_IP_ALL_INT_FLAGS); ルーチンに入ります。関数が割り込みに再突入すると、LPUART_LIN_IP_FRAME_ERR と LPUART_LIN_IP_INT_FRAME_ERR_FLAG を検出し、エラー処理を実行します。この処理が完了した後、初めてコールバック関数が実行されるために渡されます。Lpuart_Lin_Ip_FrameIrqHandler 関数の LPUART_LIN_IP_NODE_STATE_RECV_SYNC と LPUART_LIN_IP_NODE_STATE_RECV_PID にそれぞれブレークポイントを設定しましたが、この時点まで実行されませんでした。一体どんな問題が原因なのだろうか。私にとって非常に重要なことなので、お返事をお待ちしております。
こんにちは。ご要望に基づき、監視のためにLpuart_Lin_Ip_FrameErrorIrqHandlerの場所にブレークポイントを設定しました。実行中に、私のLINがこのコードと受信コールバック関数の間を行ったり来たりし、バッファがデータを受信できることがわかりました。Lpuart_Lin_Ip_FrameErrorIrqHandler 関数には、特定のエラー原因は検出されませんでした。現時点で私が確認できるのは、この関数 Lpuart_Lin_Ip_FrameErrorIrqHandler が実行中に頻繁に呼び出されているにもかかわらず、受信応答バッファは依然としてデータを受信できているということです。一定期間実行した後、この関数 Lpuart_Lin_Ip_FrameErrorIrqHandler と私のコールバック関数はループに入らなくなります。これはコミュニケーションの中断と解釈できます。問題の原因を突き止めるにはどうすればいいですか？何か帳簿を確認する必要はありますか？あ、ちなみに、最初の画像は、RTD2.0.0 バージョンでオーバーフローレジスタフラグをクリアしないというエラーについて知った後、ボックス内で手動でクリアしたことを示しています。私の理解は合っていますか？これは確かに、複数回実行した後にコールバック関数に入ることができなくなるという問題を解決しましたが、その後も通信が切断されてしまうという問題は依然として残っていました。私の説明は少し複雑かもしれませんが、あなたの助けを期待しています。大変感謝いたします。
こんにちは、 @Aoyng さん。
RECV_SYNC のケースにブレークポイントを設定すると、LIN マスターは送信を継続し、スレーブを待たなくなります。その結果、PIDフィールドとフレームの残りの部分はCPUが停止している状態で送信されるため、ドライバによって正しく処理されません。
これが同期ずれを引き起こし、観測されている「偽の」割り込みにつながる可能性が高いです。
代わりに、エラー処理パス、例えば Lpuart_Lin_Ip_FrameErrorIrqHandler() にブレークポイントを設定することをお勧めします。これらのハンドラは、実際のプロトコルエラーまたはバスエラーによって起動されます。
最初のLPUARTエラーを特定できれば、問題をさらに詳しく分析できます。
BR、ダニエル
私が上記で述べたコードに、隠れたバグがないか教えていただけますか？私のコードのロジックに問題がないか確認していただき、本当にありがとうございました。LIN通信の中断という状況に遭遇したことがないので、分析にご協力いただけると大変ありがたいです。ありがとう！
LPUART_LIN_IP_FRAME_ERR および LPUART_LIN_IP_INT_FRAME_ERR_FLAG のメッセージが LIN 通信をブロックしているようです。ハードウェア側から確認しましたか？構造的な観点から見たLIN通信ループはどうでしょうか？
こんにちは、 @Aoyng さん。
Lpuart_Lin_Ip_FrameErrorIrqHandler() が呼び出された場合、実際のフレーミングエラーが検出されたことを示します。
オシロスコープを使用して、両方のボーレートを確認してください。
リファレンス・マニュアルの77.3.2項を参照してください。ボーレート許容値。
オーバーランが発生するのは、アプリケーションが受信したデータを時間内に読み取ることができないためです。これは、優先度の高い割り込みがLIN割り込みをプリエンプトした場合に発生する可能性があります。
この動作を確認するには、LPUART割り込みの優先度を上げるか、競合する割り込みを一時的に無効にしてみてください。
先ほどのコメントについてですが、完全には理解できていません。
つまり、オーバーラン割り込みがLpuart_Lin_Ip_RxOverrunErrorProcess()で処理されていないということですか？
実行がこの関数に到達するかどうか確認していただけますか？
この関数は、オーバーラン（OR）フラグをクリアする役割を担っています。
現在の情報に基づくと、ドライバー自体を変更する必要があるという兆候はありません。
よろしくお願いいたします。
ダニエル
こんにちは。現在、私のLIN割り込み優先度は0に設定されています。優先度は最高レベルに達していると思います。私が言及したオーバーフローフラグをクリアできない状況は、dongxunという人物の投稿で見られました。この投稿は、RTD 2.0.0 ライブラリのバグに関するものです: LIN: S32K312 MCU をマスターとして使用した場合、LinID を待機中に Lin タイムアウトエラーが発生します。割り込み処理における受信オーバーフローを解消した後、2回目の実行後にプログラムが受信部分で停止するという状況は発生しませんでした。しばらくは動作していたが、その後接続が切れた。ご指摘のボーレートの問題につきましては、マスター側とスレーブ側の両方でボーレートを19200に設定しました。なぜなら、もし通信速度の問題であれば、そもそも通信が開始されなかったはずだからです。
こんにちは、 @Aoyng さん。
おっしゃる通りです。LINドライバにバグがあり、オーバーラン割り込みがデフォルトでは有効になっていません。LINドライバの初期化後にこの割り込みを有効にしてみましたか？フラグをクリアするロジックは既に実装済みです。
適切なタイミングを確保するために、オシロスコープを使用してボーレートを確認することは常に良い習慣です。
BR、ダニエル
こんにちは。LIN割り込み優先度を最高レベルに、PIT優先度を低レベルに設定しようとしていました。そうしたところ、通信は中断することなく正常に機能することが分かりました。LIN通信で切断が発生する理由を説明していただけますか？現在、FS6500チップを搭載したLINトランシーバーを使用しています。私の理解では、割り込み競合が発生した場合、フレーム損失の問題が発生するはずではないでしょうか？答えていただけますか？ご返信をお待ちしております。
あなたが目にしているのは、この設定における想定通りの動作です。LIN割り込みの優先度を上げ、PITの優先度を下げることで、LIN割り込みサービスルーチンが時間内に処理されることが保証され、これは正常な動作にとって非常に重要です。
受信した各バイトは、次のバイトが到着する前に、データレジスタから読み取らなければならない。CPUがRX割り込みを十分に速く処理しない場合、ハードウェアはオーバーラン（OR）フラグを設定します。
PIT割り込みがLIN割り込みをプリエンプトできる場合、PIT割り込みサービスルーチンは非常に短くなければならない。さもなければ、LIN ISRの実行が遅延しすぎて、受信データを見逃してしまう可能性がある。
よろしくお願いいたします。
ダニエル