MCP2515 empfängt nicht (RXWAR/RXEP)

[Roland N. (eroli)]

Hallo zusammen,

im Moment hänge ich an einer komischen Stelle fest. Es ist so, dass ich 
sehen kann, dass mein Transceiver passende Spannungspegel am RX Pin 
ausgibt (Diese Schaltung soll nur Nachrichten empfangen). Außerdem sieht 
man zyklisch auch eine kurze Flanken am TX Pin (Ist das vielleicht das 
ACK?).

Allerdings scheint der MCP2515 mit diesen Daten nicht wirklich klar zu 
kommen, da dort nach (sehr) kurzer Zeit die entsprechenden Fehler-Flags 
gesetzt werden.
Im EFLG-Register sehe ich dann die gesetzten Bits für EWARN, RXWAR und 
RXEP.

Der Bus arbeitet mit einer Baudrate von 33,333kbps. Die Einstellungen 
für die Baudrate habe ich so vorgenommen (Immer die entsprechenden Paar 
abgebildet):

CNF1: 0A  0A  4A  0A
CNF2: BE  BF  BF  B5
CNF3: 05  04  04  07

Wie ihr seht habe ich schon verschiedene Baudrates ausprobiert, damit 
mein Problem aber nicht in den Griff bekommen. Suche ich eventuell an 
einer völlig falschen Stelle den Fehler?

Ich freue mich über jede Antwort.

Vielen Dank im Vorraus!

[Thomas F. (igel)]

Roland M. schrieb:
> Die Einstellungen für die Baudrate habe ich so vorgenommen

Welche Frequenz hat dein Quarz?

[Roland N. (eroli)]

Erstmal vielen Dank für deine Antwort und entschuldige bitte, dass ich 
diese wichtige Angabe vergessen habe.

Der MCP2515 hat einen eigenen Quarz, welcher mit 16 Mhz taktet...

Da man damit, zumindest dem kvaser-Baudrate-Kalkulator zu Folge, nicht 
exakt auf die 33,333kbps kommen kann, habe ich den Bus testweise auch 
mal auf 16 kbps gesetzt. Am Fehlverhalten konnte dies leider auch nichts 
ändern (natürlich habe ich die Konfiguration mit Hilfe des oben 
genannten Tools auch angepasst).

[Thomas Forster (Gast)]

Roland M. schrieb:
> CNF1: 0A  0A  4A  0A
> CNF2: BE  BF  BF  B5
> CNF3: 05  04  04  07

Ich errechne für 33,333kbps @16MHz
CNF1: 17 09 0F
CNF2: A0 BE B8
CNF3: 02 07 04

[Roland N. (eroli)]

Hallo Thomas,

vielen Dank für deine Antwort.

Ich habe deine Einstellungen mal durchgetestet, aber leider kam es zu 
keiner Verbesserung. Die RXWAR / RXEP Fehler sind nicht verschwunden. 
Zusätzlich wird das MERRF-Flag gesetzt (Message Error Interrupt Flag, 
das wurde aber auch schon bei meinen Einstellungen gesetzt).

Was könnten denn noch weitere Fehlerquellen sein? Hat da jemand eine 
Idee?

Könnte es an einem falschem Kabel liegen? Ich benutze derzeit ein 
normales CAN-Kabel, obwohl ich eigentlich mit Single-Wire-CAN arbeite...

In meiner zyklischen CAN-Routine gehe ich übrigens so mit Fehler um:

m_Status = can_chk();   // liest CANINTF aus
volatile char buffer;
if (CheckBit(m_Status, ERRIF))
{
  buffer = 0;
  buffer = read_mcp(EFLG);   // nur zu Debug-Zwecken
}
if (CheckBit(m_Status, MERRF))
{
  can_int_clear();
  DelayMicroSeconds(10);
  m_Status = can_chk();
  if (CheckBit(m_Status, MERRF))
    can_init();    // Kompletter Reset des CAN-Controllers
}

Dies führt dazu, dass der Controller quasi dauernd resettet, da das 
MERRF Flag gesetzt wird...
(Mit Reset meine ich einen SW-Reset + Durchlauf der 
Konfigurationsroutine)

EDIT:
Ich hab euch mal Bilder von den beiden Leitungen RXCAN und TXCAN 
angehangen. Für mich sieht das doch nach einem sehr vernünftigen Signal 
vom Transceiver aus. Ist das auf der TX-Leitung sichtbare Signal ein 
ACK? Eigentlich sollen nämlich nur Daten empfangen werden...

EDIT2:
Außerdem hab ich euch auch mal die Fehlermeldung aus CANoe angehangen. 
Vielleicht beeinhaltet diese ja einen wichtigen Hinweis...

[Thomas F. (igel)]

Roland M. schrieb:
> Ist das auf der TX-Leitung sichtbare Signal ein ACK?

Keine Ahnung, wie sieht denn gleichzeitig die RX-Leitung aus? Da sollten 
ja vorher Daten rinkommen.

Bei 33kbps ist die Bit-Zeit für ein ACK 30us. Das vermeindliche ACK ist 
eher 200us lang. Passt irgendwie nicht zusammen.

CANoe benutze ich nicht, kann dazu nichts sagen.

TX/RX vertauscht?
CAN_H und CAN_L vertauscht?
Kalte Lötstelle?

[Steffen R. (steffen_rose)]

RXCAN.jpg sieht nicht nach einem ordentlichen CAN Signal aus.
Zumindest so auf den ersten Blick.

Wurde das gemessene Signal mit dem Peak gesendet oder ist des das 
zurückkommende TX Signal?

[Roland N. (eroli)]

Hallo zusammen!

Ich freue mich, dass sich nun schon zwei nette Menschen meines Problems 
angenommen haben :-)

> Keine Ahnung, wie sieht denn gleichzeitig die RX-Leitung aus? Da sollten
> ja vorher Daten rinkommen.

> Bei 33kbps ist die Bit-Zeit für ein ACK 30us. Das vermeindliche ACK ist
> eher 200us lang. Passt irgendwie nicht zusammen.

Die LOW-Phase in der TX-Leitung dauert genau 180us. Das passende Bild 
des Oszilloskops habe ich euch auch angehangen.

Außerdem wie gewünscht ein Bild zu beiden Leitungen gleichzeitig. 
Gemessen wurden diese Daten direkt am CAN-Controller.

Aufgefallen ist mir dabei, dass die rot markierten Stellen stark am 
flackern waren. Die anderen Teile waren jedoch konstant sichtbar.
Zur Pinbezeichnung (aus dem Datenblatt):
TXCAN - Pin 1 - Output - Transmit output pin to CAN bus
RXCAN - Pin 2 - Input - Receive input pin from CAN bus

Über CANoe sende ich übrigens alle 50ms eine CAN-Botschaft mit der ID 
0x322, DLC=8, Nutzdaten alle 0x00... falls das weiterhilft...

> TX/RX vertauscht?
> CAN_H und CAN_L vertauscht?
> Kalte Lötstelle?

Leitungen habe ich bereits mehrfach durchgepiepst. CAN_H und CAN_L kann 
ich nicht vertauschen, da ich den MC33897, also einen 
Single-Wire-CAN-Transceiver einsetze.

Kalte Lötstellen schließe ich auch aus, das sieht alles recht ordentlich 
aus und kontaktiert soweit sehr gut. Die Schaltung befindet sich 
übrigens im Moment noch auf Lochraster...

> Wurde das gemessene Signal mit dem Peak gesendet oder ist des das
> zurückkommende TX Signal?
Ich glaube nicht, dass ich deine Frage 100%ig richtig verstanden habe. 
Aber ich denke das Bild des Oszilloskopes sollte dir deine Frage 
beantworten. Wie das Bild gemessen wurde habe ich oben ja bereits 
ausgeführt.


Nochmals vielen Dank für eure investierte Zeit :-)

EDIT:
Die Periodendauer, gemessen an der Zeit zwischen zwei fallenden Flanken 
auf der TXCAN-Leitung, beträgt übrigens 4,14ms.

EDIT2:
Vielleicht ebenfalls interessant eine Aufnahme von ca 250ms auf beiden 
Leitungen... Die Botschaft sollte, so ist es im Programm eingestellt, 
alle 50ms gesendet werden...

[Steffen R. (steffen_rose)]

Es wäre günstiger, wenn Du Daten mit wechselnden Bits (z.B. 0x55) 
schicken würdest. Dann kann man auch besser Error Frames von normalen 
Bits unterscheiden.

Bei TXCAN kann ich schwer erkennen, ob es eine Bitzeit (Ack) oder 
mehrere Bitzeiten (Error) sind. Wie Thomas oben schon schrieb passt dies 
Zeit auch nicht. Da länger als eine Bitzeit sollte es ein Errorframe 
sein.

Die Periode der Nachricht passt zur Fehlermeldung (Ack Error). Dies ist 
eine Sendewiederholung. Das bedeutet dann aber auch, dass der CANoe dein 
TX Signal nicht sieht. Entweder gibt dein Transceiver das Signal nicht 
raus oder der CANoe ist im Listen only mode.

Den kompletten CAN Reset bei Error Passive solltes Du später nicht 
machen. Im Moment dürfte es aber die Fehlersuche vereinfachen, Man muß 
nur immer dran denken.

--------
RXEP passt dazu, dass dein MCP2512 das Signal des CANoe nicht richtig 
versteht und daher ein Error Frame sendet, welches CANoe nicht empfängt.
Möglicherweise weil das Errorframe aus Sicht des CANoe zu kurz ist. Dies 
würde bedeuten, dass die Bitraten nicht passen.

[Roland N. (eroli)]

Hallo zusammen,

ich habe mal versucht eine systematische Testreihe zu fahren. Dazu habe 
ich einen alten Transceiver für normales CAN angelötet und die 
Funktionsweise überprüft in der als mir bekannten Konfiguration.

Das bedeutet der Bus läuft mit 500 kBaud, eine Nachricht mit der ID 322, 
DLC=1,Daten=0x55 wird verschickt
--> funktioniert, Ergebnis in "1CAN500.jpg"

Danach habe ich den Bus auf 33,333 kBaud eingestellt, die Baudreite im 
Mikrocontroller angepasst und nochmals dieselbe Nachricht verschickt
--> funktioniert auch, Ergebnis in "2CAN33.jpg"

Danach habe ich dieselbe Nachricht mittels der CANoe-Software 
verschickt, ebenfalls mit 33,333 kBaud Bus-Geschwindigkeit
--> funktioniert auch, Ergebnis in "3CAN33CANoe.jpg"

Danach habe ich CANoe auf Channel 2 umgestellt. Channel 2 ist mit einem 
Single Wire CAN Transceiver ausgestattet. Also den alten Transceiver 
wieder entfernt und den ursprünglichen Problem-Transceiver 
angeschlossen.
--> funktioniert NICHT, es ergeben sich zwei Bilder:

"4SWCANunregelmaessig.jpg" erscheint eher unregelmäßig, bezeichnet als A
"5SWCANansonsten.jpg" erscheint in allen anderen Fällen, bezeichnet als 
B

Der Ablauf ist ungefähr so:
A, 1s lang B, A, 2s lang B, A, 3s lang B, A, 7s lang B und wieder von 
vorne

(Bitte diese Zeitangaben nicht zu genau nehmen, die habe ich im Kopf 
mitgezählt ;-) ).

Daraus schließe ich jetzt einfach mal, dass die Baudraten-Einstellungen 
(derzeit CNF1: 0A, CNF2: B5, CNF3: 07) korrekt sind. Auch die 
CANoe-Software müsste korrekt eingestellt sein. Ich habe nun entweder 
den CAN-Transceiver im CANCase am PC in Verdacht oder den auf meiner 
Platine... Ich werde mal versuchen ein zweites Single-Wire-CAN-Case 
aufzutreiben und dieses gegenzutesten.

Ich denke die Unregelmäßigkeit zwischen A und B hängt auch mit dem Reset 
des CAN-Controllers zusammen. Könnt ihr aus den letzten zwei Bildern 
bzw. meiner kleinen "Testreihe" noch weitere Informationen erschließen?

Vielen Dank nochmals an alle Helfer :-)

EDIT:
Ein Tester unter denselben Einstellungen mit einem anderem CANCase für 
SWCAN hat dasselbe Ergebnis erbracht. Am CANCase am PC sollte es also 
nicht liegen...

EDIT2:
Jetzt kann ich auch bestätigen, dass sich Bild A immer nur ergibt, wenn 
der Controller durch die Fehler-Flags resettet wird.

[Thomas F. (igel)]

Roland M. schrieb:
> Ich habe nun entweder den CAN-Transceiver im CANCase am PC in Verdacht

Mit Single Wire habe ich bisher nichts gemacht. Aber im CANCase-Handbuch 
steht für das Single Wire CANPiggy eine Verbindung zu VBatt (12V) an Pin 
9.

[Roland N. (eroli)]

Hallo,

damit ich euch mit neuem Stoff für hilfreiche Theorien versorgen kann, 
habe ich mir nach der Anmerkung zu den 12V auf Pin9, mal den gesamten 
Stecker während des Betriebs angeschaut. Die Messungen erfolgten diesmal 
ohne Abschlusswiderstände, damit nichts verfälscht wird.

Viele Signalkurven an den einzelnen Pins ähneln sich stark. Ich denke 
die Dateinamen sind aussagekräftig genug.

Meinen Recherchen nach müsste beim SW CAN das Signal auf Pin 7 (CANH 
beim normalen CAN) liegen.

> Aber im CANCase-Handbuch steht für das Single Wire CANPiggy eine
> Verbindung zu VBatt (12V) an Pin 9.

Bedeutet das, dass ich an Pin 9 12V abgreifen kann, oder bedeutet das, 
dass ich Pin 9 mit meiner VBatt Spannungsquelle versorgen muss?
(VBatt ist bei mir allerdings nur 8,2-8,4V, es wird ein 9V Netzteil 
verwendet, für den MC33897 sollte dies aber noch innerhalb der 
Spezifikationen liegen. Dort wird 5V <= VBatt < 13V gefordert, wenn ich 
mich nicht irre...)

EDIT:
Ich habe einen ganz ganz schlimmen Verdacht :-D
Aber bevor ich jetzt anfange etwas umzulöten, warte ich noch auf eine 
Antwort zu euch zum Thema Pin 9...
Das zugehörige Handbuch gibt es übrigens hier:
https://vector.com/portal/medien/cmc/manuals/Interfaces_Accessories_Manual_DE.pdf

[Steffen R. (steffen_rose)]

Ich kann nun auch nur noch orakeln.

Ist durchgängig von Single Wire die Rede? Kenne bisher bei CANoe nur Low 
Speed/ Fehlertolerantes CAN und High Speed CAN.

Wie sieht es mit Abschlußwiderstanden aus? Wie auch immer diese bei 
Single Wire aussehen müssen.

Kleines Aber:
CANTX und CANRX sieht bei jedem Mode gleich aus. Die Unterschiede 
bestehen nur zwischen den Tranceivern (CAN-H, CAN-L oder wie die Signale 
auch immer heißen). Deine Erklärungen suggerieren, dass Du an den CAN 
Controller Pins CANRX und CANTX gemessen hast. Wenn dem so ist, stimmt 
was mit der Transceiverbeschaltung nicht, da nicht einmal CANRX sinnvoll 
aussieht.

[Thomas F. (igel)]

Roland M. schrieb:
> Bedeutet das, dass ich an Pin 9 12V abgreifen kann, oder bedeutet das,
> dass ich Pin 9 mit meiner VBatt Spannungsquelle versorgen muss?

Das Single Wire CANPiggy braucht eine externe Versorgung an Pin9 (Seite 
21 oben). Die 9V des Netzteils sollten eigentlich reichen (sage ich als 
Laie;-)

Deine Bilder lassen orakeln, dass die Versorgungspannung nicht stabil 
ist.

[Roland N. (eroli)]

Ich möchte mich SEHR herzlich bei euch beiden, besonders aber bei Thomas 
Forster (igel) bedanken :-)

NATÜRLICH habe ich NICHT das Handbuch gelesen und NATÜRLICH war NICHT 
VBatt an Pin9 und NATÜRLICH war NICHT GND an Pin3 angeschlossen.

Kurz und knapp: Jetzt funktioniert es :-)

Unglaublich, dass ich jetzt 3 Tage damit verbraten habe vor einer 
funktionsfähigen Schaltung zu sitzen und mich grau zu ärgern, wenn 
einfach nur die Versorgungsspannung gefehlt hat. Ist ja auch logisch, 
dass das über USB versorgte CANCase auch gerne seine 12V VBatt haben 
möchte... Mit den 9V meines Netzteils gehts aber auch :-)

Nochmals, vielen herzlichen Dank :-)