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?
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.