mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik CAN kaputt? (Bit recessive Error)


Autor: RS485 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hilfe,
eine Linux CAN Rechner meldet:
 (2018-07-13 20:00:15.844795)  can0  RX - -  2000008C   [8]  00 04 04 00 00 00 00 87   ERRORFRAME
        controller-problem{rx-error-warning}
        protocol-violation{{bit-stuffing-error}{}}
        bus-error
        error-counter-tx-rx{{0}{135}}
Und ein STM32 bxcan meldet viele:
LEC 100: Bit recessive Error


Was ist kaputt gegangen?

Autor: pegel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Keine Ahnung.

Hier:
https://fabiobaltieri.com/2013/07/23/hacking-into-...

gibt es einen Absatz:

If your bitrate is wrong, you should receive a stream of errors from the 
CAN bus interface:

$ candump -cae can0,0:0,#FFFFFFFF
  can0  20000008  [8] 00 00 04 00 00 00 00 00   ERRORFRAME
        protocol-violation{{bit-stuffing-error}{}}
...

In this case, bring the interface back down, and try with a different 
bit-rate. Most common ones are 500kbps, 250kbps and 50kbps.

usw.

Vielleicht hilft das etwas weiter.

Autor: abc. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
bitstuffing-error heisst i.d.r falsche baud rate eingestellt. ansonnsten 
guck mal nach der terminierung oder passiven sternen, falls jmd. an der 
verkabellung etwas gemacht hat.

Autor: rcc (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
RS485 schrieb:
> Und ein STM32 bxcan meldet viele:
> LEC 100: Bit recessive Error

Er versucht zu senden  bekommt aber kein dominantes Bit auf dem 
pysical-layer erzeugt, also CAN-H und CAN-L bleiben auf gleichem 
Potentil. Mal die CAN-Leitungen durchmessen ob der Abschlusswiderstand 
passt bzw. ob kein Kurzschluss vorhanden ist.

Autor: Thomas O. (kosmos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
keine Ahnung wieviel Aufwand es bei dir ist. Du könntest alle CAN-Nodes 
vom Bus trennen und dann unter Beobachtung nach und nach wieder 
anstecken um den Verursacher zu finden.

: Bearbeitet durch User
Autor: Rolf M. (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Klassiker, die man immer als erstes untersucht:

Bitrate, Terminierung, irgendwo CAN high/low vertauscht.

Autor: RS485 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rolf M. schrieb:

> Bitrate, Terminierung, irgendwo CAN high/low vertauscht.
  ^^^^^^^
Die Bitrate wars.
 (Indirekt via toller stromspar Automatismen die den Takt absenken..)

Danke an alle für die vielen Debug-Ideen!

Antwort schreiben

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

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.