2

16 ビット MCU PIC24HJ64GP504 を使用して、CAN ベースのアプリケーションを作成しています。基本的には、ボードと別のノード間の通信であり、1 Mbit/s で CAN を使用してボードにデータを継続的に送信し続けます。PIC24 の ECAN モジュールを 1 Mbit/s で動作するように設定しています。最初の 10 ミリ秒の間、ECAN モジュールが反対側から着信するすべてのメッセージを受け入れるようにコードを記述し、その後、メッセージ ID 0x13 のメッセージのみを受け入れるように ECAN モジュールを再構成しました。

ここで問題が発生します... 他のノードと私のボードは同時に電源が入ります。もう一方のノードは、電源投入後約 40 ミリ秒後にメッセージの送信を開始します。しかし、ボードからメッセージを受け取ることができません。ここで、最初にボードの電源を入れ、ECAN モジュールを新しいフィルターで再構成し、落ち着いてから他のノードの電源を入れる時間を与えれば、すべてが完全に機能します。

ここで最も奇妙な部分... ボードと他のノードの間に接続された CAN バス アナライザーがあり、両方のノードの電源を同時に入れても、すべて正常に動作します...最初にボードの電源を入れる必要はありません. 異なるメーカーの 3 つの異なるバス アナライザーでこれを試しましたが、同じ結果が得られました。

私には、ECAN モジュールの再構成中に、落ち着くまでに時間がかかるように見えます。そして、バスにバスアナライザーが導入されたことで、この時間は何とか短縮され、すべてが完璧に機能するようになりました。しかし、正確に何が問題なのかはわかりません。

4

3 に答える 3

3

問題は、ACK の欠落である可能性があります。CAN-Analyzer がフレームを認識し、デバイスがエラー パッシブに切り替わらない場合があります。

バス全体が初期化されるまで、送信を保留します。

于 2012-03-15T12:56:21.737 に答える
2

また、ACKが欠落しているように聞こえます。

エラー フレームが表示されていますか (6 つの連続するドミナント ビットをトリガーするスコープを取得します)。Tx ノードが十分に認識されない場合、バスからオフになるか、アプリケーション エラー モードに入る可能性があります。

バス上でダミーメッセージを送信することで、バス上に戻すことができる場合があります。

このような状況では (スコープと同様に) 、 Saleae Logicが非常に役立つことがわかりました。物理層の Rx ピンに接続します (または、バスの監視に使用できるスタンドアロンの PHY を接続することもできます)。Saleae ソフトウェアが CAN を解釈し、何が起きているかを表示します。スコープ トリガー アウトを使用してロジックをトリガーすると便利な場合があります。

于 2012-03-16T13:01:06.150 に答える