Hallo.
Ich verwende einige STM32 und lasse diese miteinander über CAN
kommunizieren.
Funktioniert bisher fehlerfrei und ziemlich stabil.
Was passiert aber im Fehlerfall? TEC/REC zählen hoch, dann schaltet der
Controller "den Bus ab". Wenn ich ein elektrisches Problem habe, kann
mal wohl nichts mehr machen.
Aber wie löst man Situationen, in denen ein Busteilnehmer den Bus
"klemmt", weil er z.B. in einer Endlosschleife hängt und ohne Pause
sendet?
Oder gibt es noch weitere Problemsituationen, die man berücksichtigen
sollte?
Vielen Dank schon mal.
Pepe.
Pepe schrieb:> Aber wie löst man Situationen, in denen ein Busteilnehmer den Bus> "klemmt", weil er z.B. in einer Endlosschleife hängt und ohne Pause> sendet?
Dann soll der Watch-Dog im betreffenden Busteilnehmer ihn zur Ordnung
rufen und neu durchstarten.
In meinem konkreten Fall hat der Watchdog auch nicht geholfen, da meine
main() (mit Rücksetzen des Watchdogs) regelmäßig aufgerufen wurde und
nur meine CAN-Sende-Routine meinte sie hätte 2^32 Einträge zum
Verschicken. Diese Lücke hab ich zwar mittlerweile geschlossen, aber es
kann ja noch mehr geben :-)
Typischerweise gibt es noch ein Warning level. Zumindest war das bei den
Philips Controllern so.
Ab dem Zeitpunkt habe ich dann nicht mehr weitergesendet, um den
Fehlercounter nicht noch mehr zu erhöhen, bis ich wieder ein Protokoll
lesen konnte ....
Hth, Adib.
ich bin davon ausgegangen, das mit dem Bus was nicht stimmt und habe
dann selber (per Programm) nichts gesendet.
Falls dann wieder auf dem Bus eine Nachricht angekommen ist, habe ich
der Software gesagt; so jetzt kannst du wieder senden.
Also eine Art Bus-OFF, nur dass bei dem hardware implementierten Bus-Off
nach der Error Schwelle auch nichts mehr empfangen werden kann.
HTH, Adib.
--
Ein dauerndes Dominant ziehen der Busleitungen sollte der Transceiver
mit einem Time-Out blocken.
Unverständlichen Datenmüll auf den Bus absondern, weil z.B. die
Takterzeugung spinnt und dadurch die Baudrate falsch ist, sollte die
CAN-Zelle erkennen, da sie dann keine / kaum noch Acknowledges für ihre
Sendebotschaften erhält.
Einfach neu starten ist nicht in allen Fällen eine gute Lösung.
Eigentlich ist da ein Error-Passive vorgesehen, also nur noch zuhören,
ob man wenigstens die anderen noch versteht.
Pepe schrieb:> In meinem konkreten Fall hat der Watchdog auch nicht geholfen, da meine> main() (mit Rücksetzen des Watchdogs) regelmäßig aufgerufen wurde und> nur meine CAN-Sende-Routine meinte sie hätte 2^32 Einträge zum> Verschicken.
Dann setzt du den Watchdog in der falschen Routine zurück. Ohne Kenntnis
der Programmstruktur ist es schwierig, da zweckdienliche Hinweise zu
geben.
meiner Meinung nach muss jeder Teilnehmer überwachen, ob die
empfangenen Daten ausreichend aktuell und gültig sind.
Wenn nicht, muss er sich Ersatzwerte bilden oder in einen Fehlermodus
wechseln.
Ein Empfänger kann bspw. Botschaftszähler oder Checksumme auswerten, um
zu überwachen, ob der Absender korrekt arbeitet.
Möglich ist auch ein Challenge-Response-Verfahren: Als Empfänger
akzeptiert man nur Nutz-Daten, die zusammen mit einer korrekten Response
kommen, die
zu der Challenge passt, die kurz vorher geschickt wurde.
Pepe schrieb:> Oder gibt es noch weitere Problemsituationen, die man berücksichtigen> sollte?
- Daten ausserhalb Wertebereich
- Daten unplausibel in Bezug auf andere Werte
- Daten nicht aktuell genug
- Daten inkonsistent (CRC, Checksumme)
- Daten ausgefallen (Sender ausgefallen)
- TX-ErrorCount über Schwelle
- RX-ErrorCount über Schwelle
- Busoff
Bei Datenfehlern: in Fehlermodus wechslen
Bei TX-Error: kurze Sendepause
Bei RX-Error: Verhalten wie bei Datenfehler
Bei Busoff: CAN-Hardware resetten und neu aufsetzen
Zusätzlich jeweils geeignete Fehler melden und Fehlerreaktionen auslösen
Pepe schrieb:> In meinem konkreten Fall hat der Watchdog auch nicht geholfen, da meine> main() (mit Rücksetzen des Watchdogs) regelmäßig aufgerufen wurde und> nur meine CAN-Sende-Routine meinte sie hätte 2^32 Einträge zum> Verschicken. Diese Lücke hab ich zwar mittlerweile geschlossen, aber es> kann ja noch mehr geben :-)
Dieses Problem wird "babbling idiot" genannt. Also ein Node an einem
Bus, der ständig den Bus belegt indem er Unsinn sendet. In Deinem Fall
der härteste Spezialfall, daß der Unsinn zwar syntaktisch korrekte
CAN-Frames sind, aber sie auf einer höheren Protokollebene unsinnig
sind.
Hier ein Paper zu dem Thema:
https://paws.kettering.edu/~jpimente/flexcan/EFTA05_FlexCAN-paper.pdf
Dort wird ein Bus Guardian vorgeschlagen um das Problem zu lösen. Recht
aufwendig umzusetzen. Daran siehst Du daß das Problem nicht trivial ist.
Kannst Du sicher festlegen, daß ein Node in wirklich jedem
Betriebszustand maximal soundsolange am Stück senden darf?
Wenn ja, könnte man an der TX-Leitung horchen. Entweder, wenn es genau
sein muss, mit nem extra µc der CAN versteht. Das wäre so ein Bus
Guardian.
Oder, wenn es einfacher sein soll, per RC-Glied und Komparator was bei
jedem Low den C etwas aufläd, konstant durch den R immer etwas Ladungen
abfließen und wenn der Schwellwert des Komparators erreicht ist gibt es
einen Reset oder zumindest Blockade des TX.
Da nur TX low/dominant gezählt wird ist es nicht so genau.
Danke schon gleich mal für die vielen Antworten.
Daten inkonsistent (CRC, Checksumme):
Ich war bisher der Meinung, dass der CAN Controller in Hardware schon
"genügend" CRC Prüfung vornimmt.
Verwendet Ihr im Frame auch noch eine weitere Prüfung?
