CAN Babbling Idiot Protection

[Thomas S. (schlot)]

Hallo zusammen,

das CAN (in meinem Fall 2.0B)-Protokoll ist ja per se recht 
fehlertolerant, insbesondere gegen "Babbling Idiots", also Knoten, die 
außer Kontrolle geraten und Mist senden.

Mir bekannt sind z. B. folgende Mechanismen:
- Transceiver schalten automatisch die Treiber ab, wenn sie länger 
dominante Pegel schalten als es bei der niedrigsten sinnvollen Bitrate 
zwischen den Stuff Bits auftreten könnte

- Controller müssen TEC und REC implementieren, um auf massiv 
auftretende korrupte Frames zu reagieren

- Einige Controller überwachen auch hardwareseitig die Kurzschlüsse der 
CAN-Leitungen gegen andere Potentiale und melden das an den µC


Jetzt die Frage:
Wird bei CAN-Controllern wie MCP2515 oder dem im AT90CAN integrierten 
hardwareseitig verhindert, dass man den Bus mit gültigen ID 0-Frames 
blockiert?

Ich hätte tatsächlich einen Anwendungsfall, einen Bus zu Testzwecken zu 
jammen, damit andere Knoten in die Frame Timeouts laufen, was ich mir 
theoretisch mit ID 0 Länge 0-Nachrichten gut vorstellen könnte. Geht das 
z. B. mit einem AT90CAN?

[Harald A. (embedded)]

Thomas S. schrieb:
> gültigen ID 0-Frames blockiert?

Wie soll das bei GÜLTIGEN ID 0 Frames funktionieren? Da kommt einer, 
wird verarbeitet und dann kommt der nächste, wieder ID 0, usw. Klar, da 
kann man in SW diverse Maßnahmen ergreifen, z.B. Timeouts. Aber der 
Controller kann sich ja nur auf den Empfang von gültigen Nachrichten 
konzentrieren. Wenn der Frame als solches ungültig ist, wäre das eine 
Sache des Controllers - alles andere ist Sache der Software.

[Thomas S. (schlot)]

Harald A. schrieb:
> Wie soll das bei GÜLTIGEN ID 0 Frames funktionieren?

Ja, das hab ich mich auch gefragt. Aber wenn man einen Versuch wegwerfen 
muss, dann ja nicht wegen offensichtlicher Dinge, sondern wegen Fußnote 
17 auf Seite 377 im Datenblatt.
Also wollte ich sicherheitshalber nachfragen, ob ich mit einer 
hardwareseitigen Flooding Protection rechnen muss.

Danke für die Antwort!

[TestX (Gast)]

Kurze Antwort: es gibt da keinen Schutz, da es sich um legitimen Traffic 
handelt.