Ich versende zyklisch CAN Nachrichten. Ziehe ich nun die CAN Leitung ab wird der Error Handler mit Fehler HAL_CAN_ERROR_TX_TERR0 aufgerufen und danach wird nichts mehr am CAN Bus gesendet, wenn ich die CAN Leitung wieder anstecke. Damit der CAN Bus wieder sendet, rufe ich einen Software Reset auf. Gibt es noch eine andere Möglichkeit ohne den µC zu resetten, damit der CAN Bus wieder läuft? Ein löschen des CAN_FLAG_TERR0 bringt leider nichts.
Ich könnte mir vorstellen dass das evtl ein Bus OFF oder was ähnliches kommt. Wenn ich nach STM32 und CAN Bus OFF suche, finde ich z.B. das hier: https://os.mbed.com/questions/86211/How-to-disable-CAN-Bus-Off-mode/ Vielleicht hilft das schon.
Müsste er dann aber nicht ich Error Callback HAL_CAN_ERROR_BOF gesetzt haben? Er hat aber nur HAL_CAN_ERROR_TX_TERR0 gesetzt
Wenn man die Leitung abzieht bestätigt niemand mehr den Empfang ohne weitere Konfiguration sendet der CAN-Controller die Nachricht immer weiter. Man muss jetzt eben einstellen ab welcher Fehleranzahl der Controller auf Bus off geht. Vielleicht kannst du aber auch nur hcan.Init.AutoRetransmission deaktivieren.
Thomas O. schrieb: > Wenn man die Leitung abzieht bestätigt niemand mehr den Empfang ohne > weitere Konfiguration sendet der CAN-Controller die Nachricht immer > weiter. Sicher nicht ohne es aktiv so programmiert zu haben. >Man muss jetzt eben einstellen ab welcher Fehleranzahl der > Controller auf Bus off geht. Das ist aus gutem Grund ziemlich exakt definiert. Man muss schon einige Handstände machen um das zu umgehen. Zuerst wäre zu klären in welchem Zustand der Controller dann ist. Error active, Error passive, Bus Off? Was hängt sonst noch an Bus? Kommt der Controller durch Empfang von gültigen Nachrichten wieder aus dem Sumpf? Die Bits ABOM und ARR wurden ja schon angesprochen. Ich hatte mit bxCAN damit noch nie Probleme, allerdings verwende ich den HAL von ST nicht in allen Projekten.
Karl schrieb: > Thomas O. schrieb: >> Wenn man die Leitung abzieht bestätigt niemand mehr den Empfang ohne >> weitere Konfiguration sendet der CAN-Controller die Nachricht immer >> weiter. > Sicher nicht ohne es aktiv so programmiert zu haben. Doch. Wenn das Senden erfolglos war, gibt es einen automatischen Retransmit - bis der Controller auf Bus Off geht.
Wie oben geschrieben ist kein Bus Off Error im Error Callback. Habe jetzt beim Init "hcan.Init.AutoRetransmission = ENABLE;" auf Enable gesetzt anstatt Disable... jetzt funktionierts. Ab- Anstecken --> kein Fehler mehr
Rolf M. schrieb: >>> sendet der CAN-Controller die Nachricht immer >>> weiter. >> >> Sicher nicht ohne es aktiv so programmiert zu haben. > > Doch. Wenn das Senden erfolglos war, gibt es einen automatischen > Retransmit - bis der Controller auf Bus Off geht. Nein. Bei Automatic retransmit sendet der Controller weiter bis er in Error passive ist. Dann darf er laut spec nicht mehr. Das ist nicht "immer".
Karl schrieb: > Sicher nicht ohne es aktiv so programmiert zu haben. bei den CAN AVRs ist das der Standard, ohne weiteren Teilnehmer wird die Nachricht endlos wiederholt, wenn man dies nicht aktiv unterbricht. Fehlerzähler usw. muss man selbst aktiv auswerten.
Thomas O. schrieb: > bei den CAN AVRs Seit wann ist ein stm32 ein can AVR? Abgesehen davon ist eine solche Lösung ziemlich doof in dem Sinn, dass es die Intention der Fehlererkennung und abschaltschwellen unterwandert. Durch diese soll sicher(er) gestellt werden, dass der Bus von einem fehlerhaften Teilnehmer nicht Blockiert werden kann. Nicht ohne Grund haben quasi alle modernen Transceiver auch eine petmanent dominant detection.
Karl schrieb: > Seit wann ist ein stm32 ein can AVR? War noch nie der Fall und trotzdem hatte ich mit meiner Vermutung recht, ätsch bätsch. > alle modernen Transceiver auch eine petmanent dominant detection. Das hat doch überhaupt nichts damit zu tun, hier überprüft der Transceiver selber, dass er eben nicht ewig den Bus auf dominant zieht falls der Controller das z. B. befiehlt oder nicht mehr loslassen will. Dadurch ist auch die Bitrate nach unten begrenzt.
Thomas O. schrieb: > War noch nie der Fall und trotzdem hatte ich mit meiner Vermutung recht, > ätsch bätsch. Ätsch bätsch? Eben genau nicht. Egal, Troll dich.
If during one node is on line, and if this node transmits some message, it will get no acknowledgement, detect an error and repeat the message. It can become “error-passive” but not bus-off due to this reason.
Thomas O. schrieb: > Das hat doch überhaupt nichts damit zu tun, hier überprüft der > Transceiver selber, dass er eben nicht ewig den Bus auf dominant zieht > falls der Controller das z. B. befiehlt oder nicht mehr loslassen will. Echt jetzt? Das sollte doch nur zeigen, dass wesentliche Eigenschaften des CAN am besten in HW umgesetzt werden. > Dadurch ist auch die Bitrate nach unten begrenzt. Das hat doch überhaupt nichts damit zu tun ;-) Thomas O. schrieb: > detect an error and repeat the message. It can become “error-passive” > but not bus-off due to this reason. Ja genau das schrieb ich doch. Weil der Controller eben nicht "immer" weiter sendet sondern nur bis er Error passive ist. Was du vorgeschlagen hast: Thomas O. schrieb: > Vielleicht kannst du aber auch nur hcan.Init.AutoRetransmission > deaktivieren. Was Peter umgesetzt hat: Peter schrieb: > Habe jetzt beim Init "hcan.Init.AutoRetransmission = ENABLE;" > auf Enable gesetzt anstatt Disable... jetzt funktionierts. Merkst du was? Genau die Aktivierung der Automatic retransmission hat's gebracht.
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.