CAN-Bus Probleme

[S.K. (Gast)]

Hallo Leute.

Ich benutzte einen PSoC-yC von Cypress. Dieser hat einen integrierten 
CAN-Controller.

Nun möchte gerne zwei dieser Dinger miteinander kommunizieren lassen. 
Hierzu habe ich nach den CAN-Spezifikationen je Controller einen 
MCP2551-Transreceiver an den Bus gelötet. Der Bus besteht aus zwei 3cm 
Kabel (Testplatine) die an den Enden jeweils mit 120 Ohm terminiert 
werden.

Nun ist es so, dass der MCP den Bus nicht einmal auf 2.5V zieht. Selbst 
wenn ich ihn nur an die Versorgungsspannung hänge und TX/Rx nicht 
beschalte, sollte das doch mindestens funktionieren oder?
Der MCP bekommt Vdd/Ground vom Mikrocontroller. Der PIN für die 
Flankensteuerung ist auf Masse.

Hat jemand eine Idee zum Thema ?


Besten Dank

[Frank L. (florenzen)]

S.K. schrieb:

[...]
> Der MCP bekommt Vdd/Ground vom Mikrocontroller. Der PIN für die
> Flankensteuerung ist auf Masse.

Wie hoch ist denn Vdd?


Gruß
f

[S.K. (Gast)]

Vdd ist auf 5V. Könnte es vllt. am Strom liegen, so das der MCP nicht 
genug Saft vom Mikrocontroller bekommt?

[S.K. (Gast)]

Mal unabhängig vom Transceiver-Problem.

Ich möchte gerade den CAN-Controller auf Funktion prüfen. Hierzu habe 
ich einfach den Tx an den Rx des Controllers geklemmt.
Es gelingt mir eine Nachricht zu versenden (Standard-Daten-Frame/ 
Standard-CAN-Nachricht) und ich bekomme auch eine periodische Bit-Folge 
am Tx raus. Diese entspricht jedoch nicht dem Standard-Frame nach 
CAN-Spezifikation.

Meine Nachricht enthält nur 1 Datenbit. Ändere ich dieses von 0 auf 1 
wird die gesamte Bitfolge auf einmal um 3bit kürzer. Das ist doch 
eigentlich garnicht möglich oder?

Bilder habe ich mal angehängt:

Datenbit = 0; Datei ...low

Datenbit = 1; Datei ...high

Danach wiederholt sich die Folge, nach ca. 27 high-bits periodisch (in 
beiden Fällen).

[(prx) A. K. (prx)]

S.K. schrieb:

> Meine Nachricht enthält nur 1 Datenbit. Ändere ich dieses von 0 auf 1
> wird die gesamte Bitfolge auf einmal um 3bit kürzer. Das ist doch
> eigentlich garnicht möglich oder?

Doch, die Länge der Signalfolge auf dem Bus hängt vom Inhalt ab. Lange 
Folgen gleichen Pegels werden zur Auffrischung der Taktsynchronisation 
durch eingeschobene Stopfbits unterbrochen.

[S.K. (Gast)]

Jetzt wird mir einiges klarer. Ich hatte überlesen das das Datenfeld im 
Daten-Frame bis zu 8byte ist. Das bedeutet also das in diesen Rahmen 
mein Datenbit + zusätzliche Stopfbits auftreten? Wonach richtet sich 
denn die genaue Größe des Datenfeldes, ist das Controllerspezifisch?

Wenn ich mir den Signalverlauf anschaue finde ich jedoch keine festen 
Bits, wie Startbit, Id-bits, usw.. Die müssten doch wenigstens in der 
Folge zu erkennen sein. Oder handelt es sich womöglich garnicht um ein 
Daten-Frame?



Grüße Stephan

[S.K. (Gast)]

Okay, die letzten Fragen haben sich erledigt. Nach dem ich mir das 
CAN-Protokoll etwas gründlicher angeschaut habe, finde ich nun auch 
meine ID in der Bitfolge wieder ;-).

Die nächste Sache ist nun, da ich ja noch das Problem mit den 
Transceivern besitze, die beiden Mikrocontroller erstmal über eine 
Wired-And-Verbindung kommunizieren zu lassen.
(siehe: 
http://www.mikrocontroller.net/attachment/28831/siemens_AP2921.pdf)

Ich habe hier noch Verständnisprobleme. Die obige Nachricht liegt nun 
auf dem Bus an. Timing/Baudrate stimmt bei beiden. Aber sobald ich den 
Empfänger an den Bus klemme ist der Bus wieder "leer" (in diesem Fall 
auf 5V, siehe Schaltung). Beim Empfänger erhalte ich keine Daten. Woran 
könnte das liegen und wie kann ich das Problem eingrenzen?

Gruß S

[Rudi (Gast)]

Hallo,


wenn du OHNE Fehler senden kannst, dann sollte es auf der anderen Seite 
auch ankommen. Als erstes würde ich diverse Fehlerbits auf beiden Seiten 
beim Senden überprüfen. Wenn es keine Fehler gibt, liegt die Nachricht 
auf dem Bus und kann auch empfangen werden.

Evtl. hast du auch den Filter aktiviert und empfängst aus diesem Grund 
keine Nachricht ?!


Grüße.

[S.K. (Gast)]

Hi.

Ja du hast recht, es passiert was auf dem Bus. Die Nachricht wird genau 
1x gesendet und empfangen ist mir heute erst aufgefallen.
Wie sieht den eine richtige Kommunikation auf dem Bus aus? Sender sendet 
Nachricht 1x. Empfänger empfängt diese. Bus ist wieder leer?
Mir ist nämlich aufgefallen, dass sich einige Bits der Nachricht ändern 
wenn der Empfänger mit am Bus hängt.

Ich hab mir die Fehlerwerte mal angesehen und es stimmt, zumindest der 
Sender macht keinerlei Fehler.
AMR und ACR sind richtig eingestellt. Es treten, vor allem beim 
Empfänger, Sendefehler > 255 auf. Da müsste der doch eigentlich in den 
Bus-Off gehen oder? Warum macht der Empfänger eigentlich Sendefehler, 
der soll doch nur Empfangen :-)?

Die Fehlerwerte kann ich über C-Funktionen auslesen.

Besten Dank und Viele Grüße

S

[Rudi (Gast)]

S.K. schrieb:
> Wie sieht den eine richtige Kommunikation auf dem Bus aus? Sender sendet
> Nachricht 1x. Empfänger empfängt diese. Bus ist wieder leer?

Ja.

> Mir ist nämlich aufgefallen, dass sich einige Bits der Nachricht ändern
> wenn der Empfänger mit am Bus hängt.

Das ist normal. Der Empfänger (oder mehrere) schauen ob die Nachricht 
empfangen werden darf (Filter) und senden ein ACK wenn sie es dürfen. Es 
wird dem Sender also signalisiert das die Nachricht von mindestens einem 
Empfänger empfangen wurde.

S.K. schrieb:
> Es treten, vor allem beim
> Empfänger, Sendefehler > 255 auf. Da müsste der doch eigentlich in den
> Bus-Off gehen oder? Warum macht der Empfänger eigentlich Sendefehler,
> der soll doch nur Empfangen :-)?

Siehe oben.

[(prx) A. K. (prx)]

Rudi schrieb:

> Das ist normal. Der Empfänger (oder mehrere) schauen ob die Nachricht
> empfangen werden darf (Filter) und senden ein ACK wenn sie es dürfen.

Die senden auch dann ACK, wenn die Nachricht nicht in den Filter passt. 
Sie muss nur korrekt empfangbar sein.

Ein aktiviertes ACK Bit ist also kein Indiz dafür, dass sich jemand 
dafür interessiert hat.

[S.K. (Gast)]

Mhh das ist interessant. Im Moment siehts so aus. Der Sender sendet, bis 
auf vereinzelte Bitfehler, problemlos. Hängt kein Teilnehmer am Bus, 
gibts einen Ack-Error. Auf dieser Seite also alles normal.

Der Empfänger muss die Nachricht ja zumindest richtig bestätigen, sonst 
würde der Sender Ack-Error melden richtig?
Ich erhalte jedoch nicht meine übertragenen Datenbits am Empfänger. Hier 
kommt also inhaltlich nix an.

Das Problem sollte somit entweder bei der Schaltung oder am 
ACR/AMR-Filter des Empfängers zu finden sein oder?

[(prx) A. K. (prx)]

S.K. schrieb:

> Der Empfänger muss die Nachricht ja zumindest richtig bestätigen, sonst
> würde der Sender Ack-Error melden richtig?

Irgendeine Node muss es bestätigen. Nicht unbedingt diejenige, die damit 
gemeint ist.

> Das Problem sollte somit entweder bei der Schaltung oder am
> ACR/AMR-Filter des Empfängers zu finden sein oder?

Sieht so aus. Man darf CAN auch ohne Filter bzw. mit "ich will alles" 
betreiben um anschliessend per Software zu filtern. Kann u.U. einfacher 
sein als sich mit z.T. komplexen Filterstrukturen rumplagen zu müssen. 
Mindestens anfangs.

[S.K. (Gast)]

Endlich Ergebnisse.
Es lag sowohl an einem falsch eingestellten Filter als auch am falschen 
Auslesen der Empfangspuffer. Nun klappt der Nachrichtenaustausch 
erstmal. Bedeutet also diese provisorische wired-or Verbindung kann man 
für Testzwecke durchaus benutzen.

Vielen Dank erstmal für die Hilfe. Falls noch Fragen auftauchen, meld 
ich mich hier :-).