Hallo zusammen!
Ich habe in den letzten Tagen den Multimedia-CAN-Bus aus meinem Auto
mitgeschrieben und versuche nun die ganzen Nachrichten so weit es geht
zu entschlüsseln.
Dazu habe ich zwei Fragen, bei denen ihr mir vielleicht helfen könnt.
Hier mal ein kurzer Auszug aus dem Log:
(Aufbau der Zeilen: ID;RTR;Daten-Bytes)
2BB;0;87 93 CA 83 9D 58 F6 FF 60 67
323;0;4D 95 C0 DD 46 CF B5 97 60 67
323;0;87 93 CA 83 9D 58 F6 FF 60 67
324;1;4D 95 C0 DD 46 CF B5 97 60 67 0 AD A8
4C9;1;87 93 CA 83 9D 58 F6 FF
323;0;4D 95 C0 DD 46 CF B5 97 60 67
2BB;0;87 93 CA 83 9D 58 F6 FF 60 67
1) Bei den meisten Nachrichten erhalte ich 10 Daten-Bytes. Eigentlich
können in so einer Nachricht ja nur 8 Daten-Bytes enthalten sein. Ist
das jetzt ein Fehler von meinem CAN-Modul (Selbstbau), oder kann es
sein, dass Renault sich nicht ganz an die CAN-Bus-Spezifikation hält und
die Nachrichten einfach länger sind?
2) Bei den Zeilen 4 und 5 ist das RTR Bit gesetzt, also ein Remote
Frame. So ein Remote-Frame enthält aber ja eigentlich überhaupt keine
Daten-Bytes. Wie man sieht werden trotzdem welche ausgelesen. Wie kann
das sein?
Das CAN-Modul habe ich selbst gebaut mit den ICs MCP2515 und MCP2551,
wie oben im Schaltplan zu sehen. Für die Kommunikation verwende ich eine
fertige CAN-Bus-Library, die ich im Netz gefunden habe (MCP2515.zip).
Als Controller verwende ich ein Arduino Mega2560 Board, mit dem ich die
Nachrichten wie folgt abrufe:
Der MCP2515 läuft im Receive Only Mode.
Wäre spitze, wenn mir einer von euch dabei helfen kann oder vielleicht
ein paar nützliche Ideen / Hinweise dazu hat.
Vielen Dank schon mal!
Mehr als 8 Byte Daten, da würde der MCP2515 nicht mitspielen.
Ich glaube eher du solltes die Spezifikation deiner CAN Bibliothek
nochmal GENAU durchgehen. Explizit was da zum Feld dataLength steht.
An der Hardware liegt so etwas i.d.R. nicht.
1) CAN hat maximal 8 datenbytes.. wenn es irgendwas hertseller eigenes
wäre, würde dein std can controller aussteigen, da das format falsch
ist.
d.h. mit großer sicherheit hast du einen fehler in der can lib
2) fehler in der can lib
mein tipp: besorg dir eine andere lib oder anderen
controller...irgendwas stimmt da nicht...
Andi D. schrieb:> mein tipp: besorg dir eine andere lib oder anderen> controller...irgendwas stimmt da nicht...
Ja genau, irgendwas stimmt da nicht :-)! Das waren auch meine Gedanken.
Danke für den Tipp. Ich werde es dann mal mit einer anderen Bibliothek
versuchen, die von kreatives-chaos.com soll ja recht gut sein.
Oder ich schreibe mir eine eigene ;-)
P.S. Aus der "CAN Specification 2.0"
(Sept. 1991. Part B - page 49)
3.2.2 REMOTE FRAME
...
Contrary to DATA FRAMEs, the RTR bit of REMOTE FRAMEs is ’recessive’.
There is no DATA FIELD, independent of the values of the DATA LENGTH
CODE which may be signed any value within the admissible range 0...8.
...
IMHO heisst das, dass bei gesetztem RTR (recessive) in DLC etwas anderes
als 0 drinstehen DARF, auch wenn gar kein Datenfeld vorhanden sein darf.
=> Wenn RTR empfangen, dann folgen per Definition keine Daten.
Unabhängig vom Inhalt von DLC.
Und Addendum -1-
...
(1) According to the CAN Specification, no transmitter may send a
frame with DLC > 8. The case of DLC > 8 is not covered by any of the
error types defined in chapter 7.1 "Error Detection". It is neither a
Bit Error, nor a Stuff Error, nor a CRC Error, nor an Acknowledge Error.
It could be regarded as a Form Error, but the DLC belongs to the stuffed
Control Field and the Form Error is only defined for the fixed-form bit
fields (see chapter 6 "Bit Stream Coding").
So no condition for Error Signalling (see chapter 7.2) is fulfilled, the
reaction of a receiver to a DLC > 8 is not defined. The Reference CAN
Model defines as de-facto standard the assumption [if received DLC > 8
then DLC := 8], expecting to receive 8 data bytes even when the received
Data Length Code exceeds its upper limit of 8.
D.h.
Werner B. schrieb:> Aus der "CAN Specification 2.0"
Ahhhhh, vielen Dank!
Hatte mir diese Spezifikation gar nicht mehr angesehen, da in dem
Datenblatt vom MCP2515 auch die Frames beschrieben werden. Nur scheinbar
nicht so ausführlich :-).
Dann werd ich das mal so umsetzen, dass ich bei gesetztem RTR einfach
keine Daten lese und bei den anderen Frames nur maximal 8 Byte.
Ich probiers mal in den nächsten Tagen aus und schreib dann hier
nochmal, wie das Ergebnis aussieht.
Ihr seid spitze! Daumen-hoch
Tobias K. schrieb:> 1) Bei den meisten Nachrichten erhalte ich 10 Daten-Bytes. Eigentlich> können in so einer Nachricht ja nur 8 Daten-Bytes enthalten sein. Ist> das jetzt ein Fehler von meinem CAN-Modul (Selbstbau), oder kann es> sein, dass Renault sich nicht ganz an die CAN-Bus-Spezifikation hält und> die Nachrichten einfach länger sind?
Bist Du sicher, dass Renault nicht Extended Frames benutzt? Dann kommen
nach dem RTR-Bit und dem Identifier Extension Bit noch 18
Identifier-Bits.
Werner B. schrieb:> Mach das aber im Treiber "vor" dem Auslesen der Daten. Der Buffer ist ja> nur 8 byte. Sonst überschreibst du ggf den Stack etc.
Ich hatte jetzt vor die Funktion receiveCANMessage() in der library
soweit zu ändern, dass über die SPI Schnittstelle nur maximal die ersten
8 Byte gelesen und übertragen werden.
Was genau meinst du mit "vor dem Auslesen der Daten"?
Meinen wir jetzt das Gleiche?
GB schrieb:> Bist Du sicher, dass Renault nicht Extended Frames benutzt? Dann kommen> nach dem RTR-Bit und dem Identifier Extension Bit noch 18> Identifier-Bits.
Extended frames werden auch verwendet, allerdings nicht für die
Multimedia Geräte. Daher werden die vorher schon alle rausgefiltert.
Die Nachrichten, die im Log auftauchen, sind auf jeden Fall normale
frames.
Ich glaube ja, dass Dein Trace die Daten falsch darstellt.
Z.B.: 1. und 3. Botschaft:
2BB;0;87 93 CA 83 9D 58 F6 FF 60 67
323;0;87 93 CA 83 9D 58 F6 FF 60 67
Die gleichen Nutzdaten von zwei unterschiedlichen IDs? Könnte es sein,
dass Deine ersten beiden Datenbytes die ID sind oder so?
Ein Gast schrieb:> Ich glaube ja, dass Dein Trace die Daten falsch darstellt.>> Z.B.: 1. und 3. Botschaft:> 2BB;0;87 93 CA 83 9D 58 F6 FF 60 67> 323;0;87 93 CA 83 9D 58 F6 FF 60 67>> Die gleichen Nutzdaten von zwei unterschiedlichen IDs? Könnte es sein,> dass Deine ersten beiden Datenbytes die ID sind oder so?
Wie kann ich denn am besten überprüfen, ob da ein Fehler vorliegt? Mehr
als alle Register- und Bit-Adressen zu prüfen, die ich verwende, kann
ich ja kaum tun, oder?
Könnten die beiden Meldungen vielleicht auch einfach bedeuten, dass zwei
Geräte sowas wie "Ich bin eingeschaltet und bereit!" melden? Damit wären
es doch dann die gleichen Nutzdaten von zwei verschiedenen IDs.
Tobias K. schrieb:> Könnten die beiden Meldungen vielleicht auch einfach bedeuten, dass zwei> Geräte sowas wie "Ich bin eingeschaltet und bereit!" melden? Damit wären> es doch dann die gleichen Nutzdaten von zwei verschiedenen IDs.
Wenn ich CAN richtig verstanden habe (was ich allerdings wirklich
nicht ernsthaft behaupten möchte), dann kann das eigentlich nicht sein.
Die Information einer solchen CAN-Botschaft wie von Dir angesprochen
sollte nach meinem Verständnis rein über die CAN-ID ohne Nutzdaten
übertragen werden; sprich die ID 2BB bedeutet z.B. "Radio eingeschaltet
und bereit".
Hi Tobias,
ist ist natürlich immer möglich, dass die Nutzdaten von 2 IDs identisch
sind. Ich halte das aber für recht unwahrscheinlich:
- denn entweder haben die Daten in den IDs unterschieldiche Bedeutung.
Da wäre es schon großer Zufall, wenn die Datenbytes identisch sind.
- oder die Botschaft wird von einem anderen (evtl. auch dem gleichen
Steuergerät) nochmals gesendet.
Für mich sieht dein Trace so aus, dass im Wechsel 2 Botschaften gesendet
werden. Was mit den 2 Botschaften die aus der Reihe Fallen ist, weiß ich
nicht.
Wie kommen den die Botschaften Zeitlich? Die meisten CAN-Botschaften
werden ja mit einer festen Zykluszeit versandt. Wenn Du dir die
Zeitstempel mal mit ausgibst, gibt das evtl. weitere Informationen.
Was Du in der SW wie prüfen kannst, weiß ich nicht, da ich weder den
Controller noch den Transceiver näher kenne. Man könnte evtl. mal
veruschen eine Botschaft parallel mit dem DSO oder LA aufzuzeichnen und
mit den Daten aus deinem Trace vergleichen. Wenn Du da das ID-Feld mal
analysierst, siehst Du ja, ob deine ID im Trace richtig ist.
Lutz schrieb:> Wenn ich CAN richtig verstanden habe (was ich allerdings wirklich> nicht ernsthaft behaupten möchte)...
Da sind wir schon mal zu zweit ;-)!
Ein Gast schrieb:> Wie kommen den die Botschaften Zeitlich? Die meisten CAN-Botschaften> werden ja mit einer festen Zykluszeit versandt. Wenn Du dir die> Zeitstempel mal mit ausgibst, gibt das evtl. weitere Informationen.
Das werde ich mal versuchen.
Ein Gast schrieb:> Man könnte evtl. mal> veruschen eine Botschaft parallel mit dem DSO oder LA aufzuzeichnen und> mit den Daten aus deinem Trace vergleichen.
Ich habe ja inzwischen ein paar tausend Nachrichten mitgelesen und immer
die Registerbits ausgelesen, bei denen der MCP2515 die ID ablegt. Und es
kommen immer die gleichen IDs drin vor, insgesamt ca. 20 verschiedene.
Das würde dann bedeuten, dass der Chip die IDs immer falsch ablegt.
Da ich kein DSO oder LA zur hand habe, würde es da auch reichen, einfach
mal den Chip zu tauschen und schauen, ob andere Ergebnisse raus kommen?
Also, ich fasse nochmal zusammen, was ich jetzt als nächstes tun werde:
- die Funktionen der CAN lib prüfen und ggf. korrigieren
- Register- und Bit-Adressen in der CAN lib prüfen
- bei Nachrichten mit gesetztem RTR die Daten-Bytes ignorieren
- bei DLC > 8 nur die ersten 8 Daten-Bytes auslesen und den Rest
ignorieren
- Zeitstempel mit ausgeben
- MCP2515 austauschen?
Hab ich da noch was wichtiges vergessen?
Es wäre auch denkbar, dass die "60 67" am Ende jeder Botschaft
irgendwelche Werte sind die nichts mit den CAN-Daten zu tun haben, die
aber durch SW-Fehler gelesen werden und dass der Rest deines Traces
richtig ist. Die zwei letzten Bytes könnten dann irgendwelche sonstigen
Registerwerte (z.B. Konfiguration, welche ja konstant bleibt) des
MCP2515 sein.
Ist aber auch nur eine Vermutung.
Ein Trace mit Zeitstempel könnte zumindest genaueren Aufschluss darüber
geben, ob deine Angezeigten IDs plausibel erscheinen oder nicht.
Ich glaube nicht, dass der MCP einen Defekt hat. Den würde ich nicht
tauschen.
Ein Gast schrieb:> Es wäre auch denkbar, dass die "60 67" am Ende jeder Botschaft> irgendwelche Werte sind die nichts mit den CAN-Daten zu tun haben, die> aber durch SW-Fehler gelesen werden und dass der Rest deines Traces> richtig ist. Die zwei letzten Bytes könnten dann irgendwelche sonstigen> Registerwerte (z.B. Konfiguration, welche ja konstant bleibt) des> MCP2515 sein.> Ist aber auch nur eine Vermutung.
Ich denke mal, damit hast du recht. Daher werde ich ab jetzt auch immer
alles nach dem 8. Byte ignorieren.
Mal sehen, was dann zusammen mit den Zeitstempeln dabei raus kommt...
Ignorieren ist doch keine echte Lösung.
Irgendwo (HW, SW, Erdstrahlen ...) kommen die Bytes her. Ich würde die
Ursache suchen und nicht einfach weg schauen. Wenn sich herausstellt,
dass die Ursache trivial ist, macht das nichts, denn es geht darum, wie
weit man den Daten dieser Messung vertrauen kann, nicht um die zwei
Bytes.
Mehrwert schrieb:> Ignorieren ist doch keine echte Lösung.
Aber genau so steht es doch in der Spezifikation:
Werner B. schrieb:> The Reference CAN> Model defines as de-facto standard the assumption [if received DLC > 8> then DLC := 8], expecting to receive 8 data bytes even when the received> Data Length Code exceeds its upper limit of 8.
Was sollte ich deiner Meinung nach tun, anstatt zu ignorieren?
Tobias K. schrieb:> Aber genau so steht es doch in der Spezifikation:
Nö, nö; dort steht, daß der DLC Werte größer 8 annehmen kann, aber
nicht, daß auch mehr als 8 byte übertragen werden können. Wie auch; die
Buffer und damit die "Kapazität" des Chips sind ja physikalisch
begrenzt. An welcher Stelle sollen die 2 bytes denn gespeichert werden?
In so ziemlich jeder Lib wertet man den DLC aus, um die Anzahl der bytes
auszulesen; aber es kann also auch quatsch im DLC stehen.
Ok, vielleicht hab ich mit "ignorieren" das falsche Wort gewählt.
Was ich damit meinte ist, wenn der DLC einen Wert > 8 hat, dann lese ich
8 Bytes aus.
Genau.
Vielleicht bringt es was, wenn Du mal ein paar komplette CAN-Frames
loggst und postest (also auch inkl. DLC, CRC etc.). Und auch ohne die
Print-Funktionen erzeugt; einfach die Registerwerte roh auslesen. Nicht,
das nachher noch die Print-Funktionen die Ursache sind und wir an der
völlig falschen Stelle suchen.
Ok, ich werde mal was vorbereiten. Zum loggen werde ich wohl erst am
Wochenende kommen, ist etwas kompliziert: Muss ja den Laptop im Auto
haben, mit dem CAN Bus verbunden. Der Akku ist aber hinüber, daher
brauche ich Strom. Bei mir zu Hause reicht aber meine Kabeltrommel nicht
bis zum Auto. Bisher bin ich dann einfach zu meinen Eltern gefahren, da
klappt das dann ;-).
Ich versuche dann mal ein vollständiges Logging zu erhalten mit den
Rohdaten aus allen relevanten Registern, inklusive Zeitstempel.
Melde mich dann wieder, wenn ich was habe!
Thread beobachten
Seitenaufteilung abschalten