Moin, ist es eigentlich normal, dass eine CAN-node (hier ST's bxCAN) nach einem einmaligen Sendebefehl fortlaufend plappert wenn der CAN Bus (CAN_L, CAN_H) nicht am CAN Tranceiver(TI's sn65hvd232) angeklemmt ist? Der TEC (transmit error counter) steht dann auf 128 :-/ Oder habe ich das Teil falsch konfiguriert?
wenn der CAN-Controller seinen Transmit-Frame nicht rücklesen kann, bzw. dabei Fehler erkennt, wird er eine Retransnmission versuchen... Grüße Homer
Ich ginge davon aus es wird automatisch wiederholt: https://www.me-systeme.de/de/support/grundlagen/can-bus-grundlagen „Nach Abbruch der Übertragung einer fehlerhaften Botschaft beginnt der Sender automatisch, seine Nachricht erneut zu senden (Automatic Repeat Request).„
CAN't schrieb: > nach > einem einmaligen Sendebefehl fortlaufend plappert Über CAN werden viele sicherheitsrelevante Befehle verschickt, z.B. Bremslicht am Auto. Da kann sich ein Sender nicht einfach damit zufrieden geben, dass ein Befehl nicht ankommt. Mit Idiotie hat das nichts zu tun, die liegt hier ganz woanders. Georg
Dein Gegenüber muss das ACK bit auf dominanten Pegel ziehen, sonst denk dein Knoten er hätte nicht korrekt gesendet und wiederholt die Message.
RTFM schrieb: > Dein Gegenüber muss das ACK bit auf dominanten Pegel ziehen, sonst denk > dein Knoten er hätte nicht korrekt gesendet und wiederholt die Message. .. bis in alle Ewigkeit.. Das 'Automatic bus-off management' greif hier wohl nicht. Na gut - es gibt ja noch die TSR.ABRQx Bits zum Abbrechen der Übertragung..
CAN't schrieb: > Das 'Automatic bus-off management' greif hier wohl nicht. > > Na gut - es gibt ja noch die TSR.ABRQx Bits zum Abbrechen der > Übertragung.. RTFM! CAN Bus ist ein Standard, ST hat ihn höchstwahrscheinlich nach Standard in Hardware implementiert, ich würde den Fehler woanders suchen. Erarbeitet dir doch bitte erst die Grundlagen und erfrage sie dir nicht im Forum.
Ist ganz normal wenn keiner die CAN Botschaft bestätigt wiederholt sich der Sendevorgang fortlaufend. Man muss sich dann darum kümmern dass das irgendwann mal aufhört.
Oder man ignoriert das einfach weitgehend, da es ja für sich kein Problem ist das ohne Busverbindung munter weiter gesendet wird. Viel wichtiger ist doch, dass sich das Programm nicht aufhängt weil die Message-Que überläuft, oder weil die Message-Boxe(n) eben beschäftigt sind und keine neue Botschaften annehmen können.
Nicht angeschlossen heißt hier auch nicht terminiert. Das können Reflexionen sein. Die laufen ewig hin und her.
RTFM schrieb: > Dein Gegenüber muss das ACK bit auf dominanten Pegel ziehen, sonst denk > dein Knoten er hätte nicht korrekt gesendet und wiederholt die Message. Ergänzung: Jede andere aktiv am Bus teilnehmende Node muss das tun. Ob der Inhalt sie interessiert oder nicht. Weshalb ein Bus mit nur einer aktiven Node nicht funktioniert.
:
Bearbeitet durch User
Roland E. schrieb: > Nicht angeschlossen heißt hier auch nicht terminiert. Das können > Reflexionen sein. Die laufen ewig hin und her. Du hast soeben das Perpetuum Mobile erfunden. :-)
Rudolph R. schrieb: > Viel wichtiger ist doch, dass sich das Programm nicht aufhängt weil die > Message-Que überläuft, oder weil die Message-Boxe(n) eben beschäftigt > sind und keine neue Botschaften annehmen können. Von wem sollen denn Nachrichten kommen, wenn kein anderer Busteilnehmer angeschlossen ist? :)
CANalyzer schrieb: > Von wem sollen denn Nachrichten kommen, wenn kein anderer Busteilnehmer > angeschlossen ist? :) Witzbold, es geht um das Senden, oder eben nicht erfolgreich Senden können, nicht um den nicht vorhandenen Empfang. Der Versuch alle xxx ms eine Botschaft abzuschicken darf nicht zum Absturz des Programms führen weil die Message-Boxe(n) gerade nichts annehmen können.
CAN't schrieb: > Das 'Automatic bus-off management' greif hier wohl nicht. Yep. An genau dieser Stelle mit Absicht nicht. Ein Transmit Error aufgrund fehlendem ACK wird nur so lange gezählt, bis die Node den Error Passive Zustand erreicht hat, also bei 128. Von da an werden Transmit Errors nicht mehr gezählt und ein Bus Off wird folglich nicht erreicht. Hintergrund ist das Startverhalten. Die Node, die auf einem Bus als erste aufkreuzt ist erst einmal allein auf weiter Flur. Die kriegt beim Senden unweigerlich ACK Fehler. Wär blöd, wenn die dann gleich auf Bus Off liefe und sich wieder abklemmt. Folglich geht es so lange weiter, bis eine andere Node aufkreuzt und ACK liefert. Wenn die Nodes kein automatisches Bus Off Recovery implementieren (optional und beim ST einstellbar), könnte andernfalls der Zustand eintreten, dass nacheinander jede Node beim Start alsbald auf Bus Off geht und die rote Flagge setzt. Und am Ende nur rote Flaggen zu sehen sind, und ein toter Bus. ST User schrieb: > Erarbeitet dir doch bitte erst die Grundlagen und erfrage sie dir nicht > im Forum. Sei gnädig. Es steht zwar drin, aber trivial ist es nicht. Ich kann schon verstehen, wenn sich das nicht gleich erschliesst.
:
Bearbeitet durch User
Rudolph R. schrieb: > CANalyzer schrieb: >> Von wem sollen denn Nachrichten kommen, wenn kein anderer Busteilnehmer >> angeschlossen ist? :) > > Witzbold, es geht um das Senden, oder eben nicht erfolgreich Senden > können, nicht um den nicht vorhandenen Empfang. > Der Versuch alle xxx ms eine Botschaft abzuschicken darf nicht zum > Absturz des Programms führen weil die Message-Boxe(n) gerade nichts > annehmen können. Selber Witzbold. Hast du die ersten Zeilen des TO gelesen? Da geht es darum, daß am CAN-Transceiver kein BUS angeschlossen ist. Also ist da kein anderer BUS-Teilnehmer vorhanden als der Sender. Ergo kann niemand die gesendete Botschaft quittieren. CAN't schrieb: > ist es eigentlich normal, dass eine CAN-node (hier ST's bxCAN) nach > einem einmaligen Sendebefehl fortlaufend plappert wenn der CAN Bus > (CAN_L, CAN_H) nicht am CAN Tranceiver(TI's sn65hvd232) angeklemmt ist? Und du schriebst darauf: Rudolph R. schrieb: > Viel wichtiger ist doch, dass sich das Programm nicht aufhängt weil die > Message-Que überläuft, oder weil die Message-Boxe(n) eben beschäftigt > sind und keine neue Botschaften annehmen können. Das Annehmen von Botschaften ist das kleinste Problem. Wenn am BUS kein Teilnehmer als der Sender vorhanden ist, dann ist auch keiner da, der eine Botschaft schicken kann. Jetzt verstanden, was ich meine?
Roland E. schrieb: > Nicht angeschlossen heißt hier auch nicht terminiert. Das können > Reflexionen sein. Die laufen ewig hin und her. Das würde nur bei Supraleitung funktionieren!
CANalyzer schrieb: > > Das Annehmen von Botschaften ist das kleinste Problem. > Wenn am BUS kein Teilnehmer als der Sender vorhanden ist, dann ist auch > keiner da, der eine Botschaft schicken kann. Jetzt verstanden, was ich > meine? Und da typischerweise CAN-Sender ein paar "Message-Boxen" haben für ausgehende Nachrichten, kann ein einzelner Knoten schon Firmware haben, die die "Ausgangs-Queue" fluten und dann abschmieren. Message-Boxen deshalb, weil in einer Queue eine Nachricht mit geringer Prio (ID-abhängig) nicht solche mit hoher Prio blockieren soll. In jedem "Sende-Slot" kann so die Message gesendet werden, die die höchste Prio auf dem Bus hat. Aber eben nur eine der n in der HW vorhandenen und die Firmware muß das abkönnen.
CANalyzer schrieb: >> Viel wichtiger ist doch, dass sich das Programm nicht aufhängt weil die >> Message-Que überläuft, oder weil die Message-Boxe(n) eben beschäftigt >> sind und keine neue Botschaften annehmen können. > > Das Annehmen von Botschaften ist das kleinste Problem. Mensch, zum Senden annehmen, nach draussen.
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.