Hallo liebe Community,
nachdem ich die SPI Kommunikation zwischen RIO und dem MCP2515 modul
hinbekommen habe (siehe diesen Thread
Beitrag "MCP2515 SPI Kommunikation myRIO vs. Arduino" ) bin
ich nun endlich so weit die Register des CAN controllers zu setzen.
Ich habe die Register nun genau so gesetzt wie es der Arduino tut, bei
dem ich den Controller auch schon erfolgreich getestet habe. Bild 1
(RIO) Bild 3 (Arduino).
Leider bekomme ich beim RIO auf dem CAN nur Error frames. (siehe Bild
2).
Man sieht auch, dass beim RIO das Error Register rapide hoch zählt und
den Controller sofort auf "bus-off" setzt. Ich kann mir aber nicht
erklären warum. Die Fehlerbehandlung des MCP Datenblatts ist leider auch
mager zu dem Thema.
Weiß jemand was die Voraussetzung ist um das Fehlerregister hoch zu
zählen ?
Im oben angeführten Thread war noch von einem Pegelwandler für den SPI
die Rede. Kann das auch dazu führen, dass bei zu niedrigem SPI Pegel die
CAN Nachrichten nicht richtige generiert werden ? Kann ich mir aber
nicht vorstellen, da ich ja zumindest Error frames sehe.
Zu den Bilder.
Bild1: Zeigt alle Register direkt vor der "transmit"-Funktion, welche
das TXB1CTRL.TXREQ bit auf 1 setzt (beginne senden von CAN Nachricht).
Direkt daneben alle Register nach der transmit-Funktion.
Ablauf: CAN controller initialisieren -> 3* Funktion "CAN Nachricht
senden"
(Deshalb sind auch alle 3 TX Register mit CAN Nachrichten fefüllt)
Bild2: "Pinout" und CAN Modul
Bild3: Register vom Arduino. Vor und Nach transmit Funktion.
Ich habe versucht den Thread kurz zu halten in der Hoffnung alle
Informationen sind einigermaßen rüber gekommen :) Falls nicht last es
mich wissen.
Ich hoffe von euch hat jemand ein Idee was ich hier falsch mache.
Viele Grüße
H.Joachim S. schrieb:> Hast du einen zweiten Teilnehmer am Bus? Sonst gibts kein ack, Fehler> für den Sender.
Das führt "nur" zu Error Passive und dauerhafter Sendewiederholung.
Max schrieb:> Man sieht auch, dass beim RIO das Error Register rapide hoch zählt und> den Controller sofort auf "bus-off" setzt.
> Man sieht auch, dass beim RIO das Error Register rapide hoch zählt und> den Controller sofort auf "bus-off" setzt. Ich kann mir aber nicht> erklären warum. Die Fehlerbehandlung des MCP Datenblatts ist leider auch> mager zu dem Thema.> Weiß jemand was die Voraussetzung ist um das Fehlerregister hoch zu> zählen ?
Die Fehlerzähler werden bei Kommunikationsfehlern auf dem CAN Bus
erhöht. Der TX Error Counter bei Sendefehler und der EX Error Counter
bei Empfangsfehlern. Hierfür gibt es noch spezielle Regeln. Findet man
in vielen in CAN einführenden Artikeln.
> Im oben angeführten Thread war noch von einem Pegelwandler für den SPI> die Rede. Kann das auch dazu führen, dass bei zu niedrigem SPI Pegel die> CAN Nachrichten nicht richtige generiert werden ? Kann ich mir aber> nicht vorstellen, da ich ja zumindest Error frames sehe.
SPI und CAN sind zwei Paar Schuhe. Wenn die Register die erwarteten
Werte enthalten, klappts mit der SPI Übertragung. Wenn du Spannungsmäßig
ungünstig liegst (z.B. wegen 3.3V/5V) kann dies zu sporadischen
Fehlübertragungen auf SPI Seite führen.
> Zu den Bilder.> Ich hoffe von euch hat jemand ein Idee was ich hier falsch mache.
Bei CAN Kommunikationsfehlern mußt Du den CAN näher betrachten und
Details berichten.
Die ersten Schritte wären:
- Verdrahtung kontrollieren, Abschlußwiderstände?
- Bitrate nachmessen
Wird das Board allein betrieben und der Abschlußwiderstand (jumper) ist
aktiv, darf der CAN nur bis Error Passive gehen.
Steffen R. schrieb:> Die ersten Schritte wären:> - Verdrahtung kontrollieren, Abschlußwiderstände?> - Bitrate nachmessen
Abschlusswiderstände hab ich dran (120 Ohm). Nochmals extra mit
Multimeter nachgemessen.
Bitrate siehe Bild 4. 4us zwischen Zwei Samples => 250 000 bps. Sofern
der Analyzer den Error frame richtig erkennt, wovon ich aber ausgehe.
Edit: Sorry weiß nicht warum die Bilder jetzt mehrfach hochgeladen
wurden
Erich M. schrieb:> Bitrate siehe Bild 4. 4us zwischen Zwei Samples => 250 000 bps.
Aber zwischen A1 und A2 ist doch kein Bit zu sehen???
Speziell Channel 0 zeigt ein viel kürzeres Bit?
An welcher Stelle mißt du? Das kann ich den Bildern nicht so richtig
entnehmen. CANRX und CANTX?
Für die Bitzeitmessung sollte das Kvaser Interface aus sein.
Ich hab leider kein Oszi an dem man das Timing richtig ablesen könnte.
Ich habe als Vergleich nur die Tatsache, dass der Controller
funktioniert, wenn ich ihn am Arduino betreibe. An Hand der Register
sieht man ja, dass das Bittiming für RIO und Arduino das gleiche ist.
Anbei nochmal nen Analyzer Trace wenn ich den Controller an den Arduino
hänge.
Erich M. schrieb:> Ich hab leider kein Oszi an dem man das Timing richtig ablesen könnte.
Häng deinen Logiganalyzer an CANRX und CANTX des CAN Controllers.
Kannst Du A1 und A2 verschieben? Aktuell messen sie den Abstand der
"Punkte". Diese geben anscheinend den Samplepoint entsprechend der
vermeintlich erkannten oder selbst eingestellten Bitrate an.
Und hiermit scheint er bei dem fehlerhaften Signal Probleme zu haben
oder sich an Channel 1 zu orientieren.
Kannst Du mehr zum Messaufbau im Fehlerfall schreiben?
Auch jetzt im Gutfall schreibst du nichts dazu. Channel 0 diesmal offen?
Sorry hab eben erst gecheckt, dass du nicht CAN H und L meinst sondern
die Leitung vom Controller zum Transceiver.
Habe folgendes gemacht.
MCP2515 modul and Arduino Mega (VCC 3,3V).
CAN H und CAN L sowie CANTX und CANRX an den Analyzer.
Channelbezeichnungen stehen im Screenshot.
Direkt nach dem Analyzer hab ich den Kvaser angeschlossen um nochmal die
Nachricht zu überprüfen. Rate 250 kbps.
Aufbau mit RIO:
Selbe Verdrahtung wie beim Arduino.
Was evtl. noch erwähnenswert ist, in meinem RIO Programm habe ich die RX
Buffer noch gar nicht in "betrieb" genommen.
Dort is bisher nur die Initialisierung und das Senden einer CAN
Nachricht programmiert.
Erich M. schrieb:> Sorry hab eben erst gecheckt, dass du nicht CAN H und L meinst sondern> die Leitung vom Controller zum Transceiver.
CAN-H und CAN-L wären besser. Hatte aber mitbekommen, dass du nur einen
Logikanalyzer hast.
Weiß garnicht, wie CAN-H auf einem Logikanalyzer auszusehen hat.
Erich M. schrieb:> Aufbau mit RIO:
Das Signal auf CAN-RX fehlt. Daher klappts nicht. Der CAN hört auf mit
Senden, wenn er sein eigenes Signal nicht sieht.
Tippe auf einem Verdrahtungsfehler an einer Stelle, die Du umsteckst.
Steffen R. schrieb:> Das Signal auf CAN-RX fehlt. Daher klappts nicht. Der CAN hört auf mit> Senden, wenn er sein eigenes Signal nicht sieht.
Das ist eine wertvolle Information die mir bisher unbekannt war :) Mache
mich auf die Fehlersuche
Habe mein Messsetup dahingehen umgebaut, so dass ein Trigger vor dem
Initialisieren des MCP gesetzt wird, so dass ich direkt sehe was von
Anfang an los ist.
Interessanter weise kommt die aller erste CAN Nachricht richtig, die
zweite ist aber direkt Müll. Siehe Bilder. Es ist zu sehen, dass auf der
CAN Leitung kleine Störungen sind. Die spielen sich aber im 0,2us
Bereich ab. Kann dies schon zu meinen Problemen führen ? Samplerate
meines Analyzers ist übrigens 16MS/s.
Steffen R. schrieb:> Ich weiß nicht, ob du das analoge Signal auf dem CAN Bus mit dem> Logikanalyser auswerten kannst. Daher wäre ich hier vorsichtig etwas> abzuleiten.
Naja man sieht ja schon dass die erste Nachricht genau das ist was ich
sende bzw. erwarte. Außerdem, hat der Analyzer ja direkt eine
Interpretierung von "CAN" zur Auswahl. Wenn das also nicht gehen würde,
würden die das doch nicht im Programm implementieren.
Was ich aber immer noch nicht verstehe ist warum auf dem CANRX absolut
nichts zu sehen ist....
Zur Erläuterung: CAN-H und CAN-L bilden ein Differenzsignal.
[[http://www.can-wiki.info/doku.php?id=can_physical_layer:main]]
Die Peaks werden möglicherweise dadurch entstehen, dass die Spannung
zwischen CAN-L und GND knapp am Umschaltpunkt zwischen H und L des
Analyzers ist.
Was ist mit CANRX?
In 10.png sieht man mehrfach die gleiche Nachricht. Evtl. eine
Sendewiederholung. Wäre normal, wenn das Kvaser Interface aus ist.
Die CAN Analyze sollte auf dem Kanal mit CANRX laufen. CAN-H und CAN-L
sind wegen dem oben geschriebenen ungeeignet. Auf CANTX sieht man nur
die eigenene Sendenachrichten. Auf CANRX alles.
Ansonsten sieht CANTX gut aus. Für das Nachmessen der Bitrate müßte man
mehr "reinzoomen".
Wenn du wegen CANRX was geändert hast, klappts jetzt mit dem Kvaser
Interface?
Erich M. schrieb:> Naja man sieht ja schon dass die erste Nachricht genau das ist was ich> sende bzw. erwarte. Außerdem, hat der Analyzer ja direkt eine> Interpretierung von "CAN" zur Auswahl. Wenn das also nicht gehen würde,> würden die das doch nicht im Programm implementieren.
Es geht, wenn du an das Digitalsignal gehst, nicht an das Analogsignal.
Es ist ein Logikanalyzer. Dieser interpretiert eine bestimmte Spannung
als High und eine andere als Low. Dies ist für CANRX und CANTX gegeben,
für CANH und CANL nicht.
Erich M. schrieb:> Was ich aber immer noch nicht verstehe ist warum auf dem CANRX absolut> nichts zu sehen ist....
Gegenüber 9.png sieht es jetzt doch gut aus.
Jetzt werd ich total beklopt....
Hab versehendlich CANTX und CANRX am MCP gebrückt. Dann bekomm ich
wunderschöne CAN Nachrichten. Auch mit dem Kvaser.
Spricht wieder für deine Theorie, dass wenn auf dem CANRX nichts zurück
kommt geht er in den "bus-off" modus.
Jetzt ist nur die Frage, wieso gehts mit dem Arduino nur nicht mit dem
RIO. Hier gehts für mich vermutlich n bisschen zu tief in die
Elektrik/Elektronik. Kannst du mir sagen wie ich dem Problem auf die
Schliche komme ?
Schau mal, jetzt bleibt er auch im 0x15 Modus.
Erich M. schrieb:> Hab versehendlich CANTX und CANRX am MCP gebrückt. Dann bekomm ich> wunderschöne CAN Nachrichten. Auch mit dem Kvaser.
Ist die Nachricht im Simplyzer die gewollte?
EFLG 2D RX1OVR RX0OVR TXBO TXEP RXEP TXWAR RXWAR EWARN
0x15 ist TX Error Passive. Da Du nicht mehr dazu schreibst, was du alles
getan hast, ist das jetzt erstmal nichts schlimmes. Mit jeder
Sendenachricht vom MCP2515 zum Kvaser muss nun der Error Counter
zurückzählen (TEC).
Sieht jetzt eigentlich ganz gut aus.
Steffen R. schrieb:> 0x15 ist TX Error Passive. Da Du nicht mehr dazu schreibst, was du alles> getan hast
Wie oben erwähnt hab ich CANTX und CANRX kurz geschlossen. Sobald ich
das mache kommt meine Nachricht richtig auf den Bus.
> Das Signal auf CAN-RX fehlt. Daher klappts nicht. Der CAN hört auf mit> Senden, wenn er sein eigenes Signal nicht sieht.
Ich denke genau den Fehler behebe ich mit dem Kurzschluss. Ich weiß aber
eben nicht wodurch dieser Fehler entsteht. Vorallem ist der Fehler nich
vorhanden wenn ich das Board mit dem Arduino betreibe. Siehe Bild 8 mit
dem Trace vom Arduino.
Max schrieb:> Ich habe die Register nun genau so gesetzt wie es der Arduino tut, bei> dem ich den Controller auch schon erfolgreich getestet habe. Bild 1> (RIO) Bild 3 (Arduino).
CNF1 .. CNF3 passen, dann denke ich dass es vom Timing her passen
sollte, da auch der Kvaser etwas empfangen hat.
Erich M. schrieb:> Ich denke genau den Fehler behebe ich mit dem Kurzschluss. Ich weiß aber> eben nicht wodurch dieser Fehler entsteht. Vorallem ist der Fehler nich> vorhanden wenn ich das Board mit dem Arduino betreibe. Siehe Bild 8 mit> dem Trace vom Arduino.
Wo hast du genau den Kurzschluß? Kann ja nur entstanden sein, damit du
den Logikanalyzer an CANRX bekommst.
Der Fehler ist wie immer total Banane. Ein kurzer Blick in das
Datenblatt vom TJA1050 Transceiver hätte gereicht und ich hätte mir
tagelanges Fehler suchen beim MCP2515 sparen können.
Der Transceiver braucht min. 4,7V. Hab das Board aber wegen des 3,3V
SPIs nur mit 3,3V versorgt.
Habe mich auch irgendwie auf die Angabe des Onlineshops "3,3V Can
controller" verlassen.
Durch diesen Fehler scheint es so als würde auf dem CANRX Pins vom
TJA1050 nichts kommen. Wenn ich jetzt CANTX und CANRX kurzschließe dann
hab ich damit das Problem eliminiert, dass der Controller in "bus-off"
geht wenn er auf CANRX nicht mal seine eigene Nachricht sieht.
Bin deshalb gerade dabei, nen TXB104 als Level shifter zu verbauen.
Allerdings liefert der nur Müll Signale bis jetzt.... Meine MCP Register
tanzen wie wild.
Erich M. schrieb:> Bin deshalb gerade dabei, nen TXB104 als Level shifter zu verbauen.
Was willste denn damit??
Der CAN-Controller selbst läuft auch mit 3,3V. Musst also nur den
Transceiver wechseln.
Max schrieb:> Naja ist so n Modul wie oben auf dem Bild. Da will ich nicht unbedingt> anfangen den Transceiver zu wechseln
Ein SO8 lässt sich doch völlig problemlos wechseln. Lieber bastelst du
Pegelwandler dazwischen? Und wohin denn überhaupt?
Entweder zwischen CAN-Controller und Transveiver, da musst du diese
Leitungen auftrennen und ausserdem Vcc und die Sache mit 5V und mit 3,3V
versorgen, also auch auf der Platine rumwerkeln.
Oder eben zwischen deinen Prozessor und und dem CAN-Controller als
Zwischenplatine. Wenn du es richtig machen willst, brauchst du dann 5
Pegelwandler. Ausserdem 3,3V und 5V.
Ich würde da auf jeden Fall den TJA wechseln.
H.Joachim S. schrieb:> Ich würde da auf jeden Fall den TJA wechseln.
Hm auch wieder war. Kannst du mir einen Transceiver empfehlen den ich
einfach austauschen kann?
Wenn dein TJA diesselbe Pinbelegung hat ja. Ich denke schon, ist ein
quasi-Standard. Alle, die ich bis jetzt in den Fingern hatt waren
pinkompatibel (MCP2551, 82C250/51)
Ich mein passt das auch von den Kondensatoren etc also von der
verschaltung. Bin auf dem Gebiet nicht so fit deshalb würde ich gern
sicher gehen das es funktioniert
