1. ホーム
  2. 製品・技術情報
  3. KVASER CANプロトコルとは?(CANプロトコルチュートリアル)

製品・技術情報

KVASER CANプロトコルとは?(CANプロトコルチュートリアル)

  • 2022.02.22
PART 5:オシロスコープの写真

これは、完全に正常なISO 11898のCANバスを1Mビット/秒で動作させたものです。トランシーバは82C251で、物理層はISO 11898で指定されたものを使用しています。

測定は、CAN_HとGND間で行いました。静止状態のバス電圧とリセッシブバス状態のバス電圧は2.5V前後であることに注意してください。ドミナントビットが送信されると電圧は約3.5Vまで上昇します。

これは同じバスですが代わりに測定は、CAN_LとGNDの間で行いました。

これは125 kbit/sで送信された別のメッセージです。
メッセージの(11ビット)識別子は300、つまり16進数で12cです。よく見るとメッセージの最初のビットを識別できるはずです

ここにトリッキーな写真があります。これは上と同じメッセージを示しており(11ビット)識別子300、125 kbit/sと変わりませんがCAN bus上でターミネーションをしていません。CANケーブルは、短いフラットリボンケーブルを使用しています。

それで何が起きているのでしょうか?これは125kbit/sなので1ビットが8μsになります。

  1. 最初にトランスミッタがスタートビットを送信します。これは論理'0'、すなわちドミナントレベルです。
  2. 次に、識別子が送信されます。10進数300、16進数で12c、または2進数で001 0010 1100です。最初の2つのゼロは、問題なく送信されたように見えます。これは、画像に見られるような24μsのドミナントレベルを説明しています。
  3. 次に'1'が送信されるはずですが、バスが終端していないので立ち上がりスロープ(rising slope)は、本来あるべきものではありません。送信ノードは、バス上の'0'を見たと考えるでしょう。
  4. これは調停フェーズ中で起こるのでトランスミッタは、送信を停止します。即ち、それは他のノードが送信していると、考えます。実際には誰も送信していないので、バスは、レセッシブのままになります。
  5. 6つのレシビティビットの後、トランスミッタとレシーバの両方がstuff errorを検出し、エラー処理が開始されます。この時点で、80μsが経過しています(1スタートビット、2つの'0'、1つの誤解釈ビット、6レセッシブビット、合計10 bits= 80μs)。
  6. stuff errorを検出したノードは、エラーフレームの送信を開始します。この場合、上記の画像がキャプチャされる前に多数のエラーが発生しているためエラーフレームはpassiveであるのでトランスミッタはerror passiveです。passive errorフレームは、activeエラーフレームと同じですが、レセッシブレベルで送信されるのでバス上では見えません。
  7. passiveフレームは、6ビットを6回続けます。
  8. 次にすべてのノードは、error delimiterと呼ばれる8レセッシブビットを待ちます。
  9. 次にすべてのノードは、intermissionと呼ばれる3レセッシブビットを待ちます。
  10. 上記の数値を合計すると、1+6+6+8+3= 24 レセッシブビット = 192μsに達します(画像を参照してください!)。

モラル:常にCAN busをターミネートさせましょう! 反射は必ずしも傷つけるわけではありませんが、エッジのシェープが悪いと通信障害が発生します。

同じCANバスを別の時間軸で見てみましょう。

CAN busの長さは、約2デシメータ(8 in.)です。アンダーシュートおよびリンギングが見えますが、この場合、さほど重要ではありません。今回は、遅い立ち上がりのエッジが問題の原因です。

これは同じ設定ですが、今回はトランスミッタとレシーバの両方がerror activeになっています。

何が起こっているのでしょうか?

  1. 上記の写真のように、3つの'0'が送信され(24μsかかります)、次のビットは、誤って解釈されるため、トランスミッタは、調停を失ったと考えます。
  2. ランスミッタは、6ビットを待ってからstuff errorを検出します。誤解釈されたビットと6 ビットは、56μsを要します。
  3. トランスミッタとレシーバがエラーフレームの送信を開始します。それは6ドミナントビット(48μs)です。
  4. エラーフレームを送信したノードは、8レセッシブビットを待ちますが、立ち上がりのスロープが悪いため、最初のビットが誤解釈されます。ノードは、これはエラーフレームを送信している別のノードであると考え、それを無視します。
  5. バスがレセッシブレベルに戻ると、すべてのノードは、8ビットを待ちます。
  6. 次に3レセッシブビットのintermissionがきます。
  7. 3+9=12ビット=96μs (写真に示されています)。
  8. その後、トランスミッタは、同じ結果で再試行します。しばらくすると、トランスミッタは、error passiveになり、前述のように動作します。

ここにさらに別の写真があります。この設定では、適切に終端されたCAN bus上のシングルノードしかありません。メッセージを送信しようとしていますが、誰も聞いていません。

では、何が起きているのでしょうか?

  1. まずトランスミッタは、メッセージ全体を送信します。
  2. トランスミッタは、ACKスロットにドミナントレベルを期待しますが誰もlisteningしていないのでACKがきていないことからトランスミッタは、Acknowledgementエラーを検出します。
  3. その後、トランスミッタは、passive errorフラグを送信します(上の画像では数秒間送信しようとしているためpassiveであり、もはやError activeではなくなりました)。
  4. passive errorフラグの後にはエラーデリミタintermissionが続きます。
  5. このノードは、メッセージを送信しようとしたが失敗したので新しい送信を開始する前に別の8ビットを待つ必要があります。これはCAN仕様では'suspend transmission'(送信の中断)と呼ばれます。
  6. 送信ノードもまた、txエラーカウンタを8増やさなければなりませんが、CAN仕様の特殊なケースではトランスミッタがerror activeな場合のみ発生します。トランスミッタがエラーになると、トランスミッタは(この場合は)txエラーカウンタを増やすことができず結果的に送信は永遠に再試行されます。

従って、画像に表示されているのは、メッセージが送信され、その後、エラーフラグ、エラーデリミタ、中断、送信の中断の合計である小さな一時停止が続きます。メッセージは、その後が再送信され、そして再送信され、そして・・・