Hallo an alle,
ich versuche gerade den Can Fehlerbehandlung zu verstehen. Mir geht es
primär darum ob meine Gedanken richtig sind...Das Wissen dabei habe ich
zum größtenteils auf der Verctor Homepageseite her.
Nun zu den Fragen. Im Anhang befindet sich ein Teil des Can Netzwerk
Topologie zur besseren Verständnis.
Sei gegeben Fehler 1: Der Can Knoten ist vom Bus getrennt.
Was passiert?
Meine Antwort: Der Sender versucht die Telegramme zu schicken, aber
bekommt keinen dominantes ACK, somit inkrementiert sich der
tx-errorcounter bis 128 und geht in den error passiv Zustand.
Sei gegeben Fehler 2: Nur Leitung RX ist unterbrochen.
Was passiert?
In diesem Fall erkennt das Bitmonitoring den Fehler, weil es
Unterschiede zwischen den gesendeten Daten und Buspegel gibt. Wiederholt
die Daten zu senden bis RX errorcounter auf 128 ist.
Sei gegeben Fehler 3: Nur Leitung TX ist unterbrochen.
Was passiert?
Da kein ACK von den Empfänger ankommen wird, wird der tx-errcounter auch
hier hochgezählt
Ich hoffe ihr könnt mir dabei Helfen, da ich mit dem Skript vom Prof.
nicht so ganz klar komme. Ich brauch die Sicherheit, dass ich es
zumindest ansatzweise Verstanden habe.
Vielen Dank und Grüße
CS
dunno.. schrieb:> Kommt auf den rest des busses an. Ack senden alle knoten..
Genau. In diesem Fall sollte mein Schaubild nur ein ausschnitt sein mit
mehreren Knoten. Wollte nur nicht, dass das "Schaubild" überladen wird.
Sind meine Erklärungen in diesem Fall plausibel?
LG
Counter S. schrieb:> Sei gegeben Fehler 1: Der Can Knoten ist vom Bus getrennt.> Was passiert?> Meine Antwort: Der Sender versucht die Telegramme zu schicken, aber> bekommt keinen dominantes ACK, somit inkrementiert sich der> tx-errorcounter bis 128 und geht in den error passiv Zustand.
Richtig
> Sei gegeben Fehler 2: Nur Leitung RX ist unterbrochen.> Was passiert?> In diesem Fall erkennt das Bitmonitoring den Fehler, weil es> Unterschiede zwischen den gesendeten Daten und Buspegel gibt. Wiederholt> die Daten zu senden bis RX errorcounter auf 128 ist.
Ja wenn RxD floatend high ist. Wenn die offene Leitung auf Low geht wird
ein dominater Pegel erkannt. Damit sollte der Knoten bereits in der
Arbitrierung aufgeben, er glaubt dann der Bus wäre belegt.
> Sei gegeben Fehler 3: Nur Leitung TX ist unterbrochen.> Was passiert?> Da kein ACK von den Empfänger ankommen wird, wird der tx-errcounter auch> hier hochgezählt
Richtig.
soul e. schrieb:> Counter S. schrieb:>>> Sei gegeben Fehler 1: Der Can Knoten ist vom Bus getrennt.>> Was passiert?>> Meine Antwort: Der Sender versucht die Telegramme zu schicken, aber>> bekommt keinen dominantes ACK, somit inkrementiert sich der>> tx-errorcounter bis 128 und geht in den error passiv Zustand.>> Richtig
Macht mein bxCAN nicht - der sendet bis zum Sankt-Nimmerleinstag..
dunno.. schrieb:> Kommt auf den rest des busses an. Ack senden alle knoten..
Nö, nur die Knoten senden ein ACK, die sich für eine Nachricht
"interessieren" (also wo sie durch den Filter kommt).
tinCAN schrieb:> Macht mein bxCAN nicht - der sendet bis zum Sankt-Nimmerleinstag..
So kenne ich das (leider) auch.
Die Problematik ist aber eigentlich eher akademisch...
Die Anzahl der Fälle in denen RX oder TX zwischen Transceiver und
Controller unterbrochen wird, ist sehr klein. Beim Auto kann ich mir das
gerade nur vorstellen, wenn es eh egal ist (Unfall bei dem das
Steuergerät mechanisch beschädigt wird).
Normalerweise ist der Fehler dann doch eher jenseits des Transceivers an
den Busleitungen - Unterbrechung oder Kurzschluss (untereinander oder
nach Masse/Versorgung).
mmm schrieb:>> Kommt auf den rest des busses an. Ack senden alle knoten..>> Nö, nur die Knoten senden ein ACK, die sich für eine Nachricht> "interessieren" (also wo sie durch den Filter kommt).
Ich kenne es auch so, dass alle formal korrekten Botschaften ein ACK
erhalten, auch wenn sie niemanden interessieren.
> Sei gegeben Fehler 3: Nur Leitung TX ist unterbrochen.> Was passiert?
Auch hier sollte das Monitoring des RX - Pins schon einen Fehler zeigen,
lange bevor man am ACK Bitslot ist.
Der Transceiver sollte sein Ende der TX Leitung mit einem Widerstand so
hinziehen, dass er daraus den Pegel für rezessiv macht. Sollte der TX
Pin dauerhaft ein dominat befehlen, schlägt das Timeout im
CAN-Transceiver zu.
In allen diesen Fällen erkennt der CAN-Controller, dass die über RX
gemeldeten Zustände des Busses nix mit dem zu tun haben, was er gerade
ausgeben wollte.
Bzw. erkennen alle Busteilnehmer eine Error-Condition, weil bei normaler
Übertragung längst ein rezessives Stuffbit eingeworfen worden sein
müsste.
> Macht mein bxCAN nicht - der sendet bis zum Sankt-Nimmerleinstag..
Die Error Counter sind in Software (sprich im Can-Treiber) realisiert,
oder halt nicht, wenn billig statt standardkonform bei der Entwicklung
im Vordergrund stand.
tinCAN schrieb:> Macht mein bxCAN nicht - der sendet bis zum Sankt-Nimmerleinstag..
Falsch konfigurierte Softwarestacks zeichnen sich dadurch aus, dass ihr
Verhalten nicht der Spezifikation entspricht.
Unter Umständen kann das ja auch gewollt sein: ein Diagnosetester darf
ruhig solange alleine in die Welt hineinsenden, bis ein Steuergerät
angeschlossen wird und antwortet. So muss man das Anklemmen nicht
jedesmal neu bestätigen. Geräte, die ausschließlich im Systemverbund
laufen, sollten sich aber spezifikationskonform verhalten und error
passive unterstützen.
mmm schrieb:> Die Problematik ist aber eigentlich eher akademisch...
Du hast es erfasst! Ich selbst besitze kein Can Controller. Ich bereite
mich nur für die Klausur vor. Da andere Freunde von mir auch nicht
sicher waren und bis jetzt mikrocontroller.net immer mir helfen konnte,
war ich gezwungen meine Fragen hier zu schreiben.
LG
fop schrieb:> Auch hier sollte das Monitoring des RX - Pins schon einen Fehler zeigen,> lange bevor man am ACK Bitslot ist.> Der Transceiver sollte sein Ende der TX Leitung mit einem Widerstand so> hinziehen, dass er daraus den Pegel für rezessiv macht. Sollte der TX> Pin dauerhaft ein dominat befehlen, schlägt das Timeout im> CAN-Transceiver zu.> In allen diesen Fällen erkennt der CAN-Controller, dass die über RX> gemeldeten Zustände des Busses nix mit dem zu tun haben, was er gerade> ausgeben wollte.> Bzw. erkennen alle Busteilnehmer eine Error-Condition, weil bei normaler> Übertragung längst ein rezessives Stuffbit eingeworfen worden sein> müsste.
Super Danke!
LG CS
soul e. schrieb:> tinCAN schrieb:>>> Macht mein bxCAN nicht - der sendet bis zum Sankt-Nimmerleinstag..>> Falsch konfigurierte Softwarestacks zeichnen sich dadurch aus, dass ihr> Verhalten nicht der Spezifikation entspricht.
bxCAN ist HARDWARE..
soul e. schrieb:> Counter S. schrieb:>>> Sei gegeben Fehler 1: Der Can Knoten ist vom Bus getrennt.>> Was passiert?>> Meine Antwort: Der Sender versucht die Telegramme zu schicken, aber>> bekommt keinen dominantes ACK, somit inkrementiert sich der>> tx-errorcounter bis 128 und geht in den error passiv Zustand.>> Richtig
Richtig?
So schweigen sich z.B. zwei Knoten in einem zwei-Knoten-Bus gegenseitig
an, auch nach dem sie wieder miteinander verbunden sind.
Restbus-Simulant schrieb:> Richtig?
Was willst du uns sagen?
> So schweigen sich z.B. zwei Knoten in einem zwei-Knoten-Bus gegenseitig> an, auch nach dem sie wieder miteinander verbunden sind.
Kann man so nicht sagen. Ein Knoten besteht ja nicht nur aus dem
CAN-Controller, sondern auch aus einem Mikrocontroller mit Firmware
drauf.
Geht der CAN-Controller in einen Fehlermode so hängt das weitere von der
eigentlichen Firmware ab: Versucht diese zu einem späteren Zeitpunkt
nochmals aktiv das Senden? Oder geht der Knoten in ein Notfallprogramm
ohne Kommunikation? Oder schaltet er sich komplett ab? Oder....
mmm schrieb:> Nö, nur die Knoten senden ein ACK, die sich für eine Nachricht> "interessieren" (also wo sie durch den Filter kommt).
Das ist falsch.
Die message muss formal korrekt sein, dann gibts ein ack. Der Filter
kommt erst danach.
Wenn lediglich das ACK vom Bus fehlt, sendet der Knoten natürlich
weiter.
Ggf bis zum Sankt-Nimmerleinstag.
Aufgrund der ACK geht der Tx Errorcount hoch bis 128 und der Knoten ist
dann Error passive. Aber auch in diesem Zustand darf der Knoten senden.
Im Zustand Error Passive wird Tx Errorcounter bei ACK Fehler nicht
inkrementiert.
> Sei gegeben Fehler 1: Der Can Knoten ist vom Bus getrennt.> Was passiert?> Meine Antwort: Der Sender versucht die Telegramme zu schicken, aber> bekommt keinen dominantes ACK, somit inkrementiert sich der> tx-errorcounter bis 128 und geht in den error passiv Zustand.
Richtig. Und auch in error passive wird der Frame weiter wiederholt.
Der Tx Errorcounter wird in error passive aber nicht aufgrund eines
ACK-Fehlers inkrementiert.
> Sei gegeben Fehler 2: Nur Leitung RX ist unterbrochen.> Was passiert?> In diesem Fall erkennt das Bitmonitoring den Fehler, weil es> Unterschiede zwischen den gesendeten Daten und Buspegel gibt. Wiederholt> die Daten zu senden bis RX errorcounter auf 128 ist.
Wenn beim Senden der rückgelesene Pegel nicht dem gesendeten entspricht,
wird aber nicht der Rx, sondern der Tx Errorcounter erhöht.
Wenn die Leitung dauerhaft unterbrochen ist, versucht der Knoten
fortlaufend den Frame zu senden und erhält ständig Bit Fehler.
Nach 16 Versuchen (Tx Errorcount = 16*8 = 128) geht der Knoten nach
Error passive.
Nach 16 weiteren Versuchen (Tx Errorcount = 32*8 = 256) geht der Knoten
nach BusOff.
Dann sendet er wirklich nicht mehr. Empfang geht auch nicht mehr.
Der Zustand kann nur verlassen werden, wenn das von außen angestoßen
wird.
(Erkennen und Behandeln des Busoff Zustands in der Software)
> Sei gegeben Fehler 3: Nur Leitung TX ist unterbrochen.> Was passiert?> Da kein ACK von den Empfänger ankommen wird, wird der tx-errcounter auch> hier hochgezählt
Eigentlich wie Fehler 2. Der Knoten geht auch ziemlich flott nach
Busoff, wenn er versucht zu senden.
Einziger Unterschied zwischen Fehler 2 und Fehler 3:
Bei unterbrochener Rx Leitung ist der Empfang weiter möglich.
Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.
Wichtige Regeln - erst lesen, dann posten!
Groß- und Kleinschreibung verwenden
Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang