Hallo,
ich bin bei der Entwicklung einer CAN-Schnittstelle auf folgendes
Problem gestoßen:
In einem ersten Projektt habe ich eine CAN-Kommunikation zwischen einem
XE167 und einem XC167 von Infineon realisiert. Diese lief dann auch ohne
Probleme.
In einem nachfolgenden Projekt habe ich den 8-Bit Prozessor XC886 von
Infineon eingesetzt. Initialisierung per DAVE, Übernnahme der Sourcen
vom ersten Projekt.
Die Grundfunktion war dann auch da, d.h. einzelne CAN-Objekte konnten
zwischen den Controllern gesendet werden. Dann folgte der Dauertest, und
damit fing das Fiasko an:
Beim zyklischen Senden von CAN-Objekten vom XC886 zum XE167 Prozessor
brach die Kommunikation nach einigen tausend Telegrammen ab und der
CAN-Knoten im XC886 deaktivierte sich (aufgrund der zahlreichen
Telegrammfehler).
Habe dann Testweise den XE167 Knoten durch den XC167 aus dem ersten
Projekt ersetzt und da funktioniert die Kommunikation !!!
Per Oszi habe ich festgestellt, daß im Fehlerfall irgendwas am
Telegrammende nicht stimmt, es sieht so aus, als ob es zur
Treiberkollision kommt. Nach Ausschluß diverser Fehlermöglichkeiten
ist mir aufgefallen, daß der Fehler immer beim Senden des gleichen
Wertes auftritt. Letztendlich hat sich herausgestellt, daß das Problem
durch eine mangelnde Synchronisation der CAN-Controller kommen muß.
Eine Veränderung des "resynchronisation-jumps" von 2 auf 4 "time quanta"
in den DAVE Schnittstelleneinstellungen hat das Problem gelöst.
Mich wundert, daß hier derartige Anpassungen auf unterster Ebene
erfolgen müssen, zumal die reale Baudrate bei den Controllern auf genau
100 000 kBaud steht und daher die default-Synchronisation ausreichen
sollte.
Die Funktion im Labor ist jetzt zwar ok, aber gewisse Bedenken bestehen
jetzt schon bezüglich der Stabilität im Serieneinsatz.
Wenn ein derartiges Problem nicht beim Testen erkannt wird und erst
später in der Serie auftritt, ist das ja kaum zu finden, zumal die
Desynchronisation nur bei bestimmten Bitfolgen auftritt.
Jetzt meine eigentliche Frage:
Hat jemand Erfahrungen mit solchen Einstellungen bzw. Anpassungen im
Timing zwischen verschiedenen CAN-Controllern ?
Gruß Holger B.
Da stimmt etwas nicht.
Ich arbeite seit Jahren mit "resynchronisation-jumps" von 1.
Wie sehen deine Signale aus?
Kannst du deine Quartzfrequenz wirklich (ohne Rest) auf das 8-32 fache
deiner Bitrate teilen?
Mess mall die Bitlängen der drei Kontroller genau nach.
Mehr fällt mir zZ. nicht ein.
Holger B. schrieb:
> Eine Veränderung des "resynchronisation-jumps" von 2 auf 4 "time quanta"> in den DAVE Schnittstelleneinstellungen hat das Problem gelöst.
Klingt für mich stark danach, dass der Takt des Controllers sich zu sehr
unterscheidet.
Holger B. schrieb:
> Beim zyklischen Senden von CAN-Objekten vom XC886 zum XE167 Prozessor> brach die Kommunikation nach einigen tausend Telegrammen ab und der> CAN-Knoten im XC886 deaktivierte sich (aufgrund der zahlreichen> Telegrammfehler).
Bist du sicher das der XC886 vom externen Quarz und nicht vom internen
Oszi befeuerti wird? Der interne ist zu ungenau und driftet mit der
Temperatur (wenn der Controller "warmgelaufen" ist), was dein Fehlerbild
erklären könnte. Was auch passieren kann: Der xc886 schaltet von allein
auf den internen Takt um, wenn es Probleme mit dem externen gibt.
BTW: Der DAVE macht auch nicht immer alles richtig. Manchmal lohnt es
sich nachzukontrollieren, leider :-(
Hallo,
erstmal Danke für die Hinweise.
@ Volker Zabe:
Ich betriebe den CAN-Bus mit 100 KBaud. Die Bitzeiten von Sender und
Empfänger habe ich kontrolliert, diese betragen 10 µsec - sollte also
auch kein Problem sein.
Ich werde mal testweise den gleichen Treiber an der nicht
funktionierenden Platine einsetzen wie bei den anderen Boards.
Mit welchen Prozessor arbeitest Du ? Mich würde interessieren, wieviel
Zeit bei Dir ein "resynchronisation-jump" ausmacht.
Wenn ich bei dem XE167 die Zeitquanten verändere, sodaß ein Quantum
anstelle 1 µsec nun 1,66 µsec beträgt, dann kann ich den
"resynchronisation-jump" auf 2 einstellen und die Kommunikation läuft
fehlerfrei (prinzipiell habe ich dann wieder etwa dieselben Bedingungen
als mit 1 µsec Zeitquantum und 4 jumps) - aber mit verlängertem
Sync-Segment.
@ Andreas R.:
Den XC886 hatte ich mit dem internen Oszilator betrieben. Eine
Umstellung auf externen Quarz hat das Fehlerbild leicht verändert (jetzt
kommen zumindest einige Fehlerfreie Telegramme durch), aber das Problem
nicht gelöst.
Holger B. schrieb:
> @ Volker Zabe:> Ich betriebe den CAN-Bus mit 100 KBaud. Die Bitzeiten von Sender und> Empfänger habe ich kontrolliert, diese betragen 10 µsec - sollte also> auch kein Problem sein.> Ich werde mal testweise den gleichen Treiber an der nicht> funktionierenden Platine einsetzen wie bei den anderen Boards.>> Mit welchen Prozessor arbeitest Du ? Mich würde interessieren, wieviel> Zeit bei Dir ein "resynchronisation-jump" ausmacht.>
Ich Arbeite mit Renesas M16C-Serie.
Meist : 125kbit/s (1Bit=8µs) Tq=16 (bevorzugt)
=> 1 Tq = 0,5 µs.
In 11b-ID Frame kann 111 bits(ohne Stuff) lang sein, ein 29bit-ID Frame
sogar bis zu 155 bits. Macht (125k) 1,24ms. 0,5µs/ 1240µs = ca. 0,04%
Also 0,04% dürfen die beiden Tackte diferieren.
Zeig doch mal die CAN-H und CAN-L besser diff) Leitung beim Fehler.
Vielleicht kann man da mehr sehen. zb. Lage des Errorframes, Flanken
etc.
Sonst Raten wir uns noch zu Tode.
O.K., das habe ich befürchtet, dass Du .dip 2.1 verwendest.
Bei dieser Version wurden die PLL Einstellungen für 66 MHz aus versehen
auf 67 Mhz gesetzt. Das führt zu einer falschen CAN Baudrate.
Bei der Version .dip 2.0 ist das noch richtig gewesen. Ich hängs Dir mal
an da es nicht mehr auf der Website ist. Probiere das ganze einfach mal
mit der PLL Einstellung von .dip 2.0.
Gruß
Tannenzaepfle
Hallo Tannenzaepfle,
da muß man erstmal draufkommen !
Kommunikation läuft jetzt einwandfrei.
Da haben die Jungs von Infineon mal wieder ganze Arbeit geleistet.
Beim DIP-File 2.1 gibt es Fehlermeldungen beim Import der
Systemeinstellungen in die Tasking-EDE (FCONCS*-Register), die mit dem
DIP2.0 nicht auftrteten.
Ich werde zunächst mit der Version 2.0 entwickeln, bis ein hoffentlich
deutlich verbessertes DIP verfügbar ist.
Nochmals Danke für den Tip,
Gruß Holger
Rothaus Bier schrieb:
> Bei dieser Version wurden die PLL Einstellungen für 66 MHz aus versehen> auf 67 Mhz gesetzt. Das führt zu einer falschen CAN Baudrate.
Wo kann man das nachlesen?
Habe ein ähnliches Problem, und genau das war die Ursache dafür.
Kann dies aber weder im Dave-erzeugtem-Code nachvollziehen noch auf
irgendeiner Seite von infineon nachlesen.
Die oben genannten 2 Zeilen sind das einzige was ich im Web dazu
gefunden habe.
Gibt es eigentlich irgendwo eine Errata Seite für den DAVE und die
DIP-Files?
Tritt dieser Efekt nur bei 66Mhz auf ?
Dann wäre es nicht so schlimm, momentan Arbeite ich noch mit dem
Evaluations-Board.
Bald mit der eigenenen Platine mit einem 80Mhz XE164, stimmen dann da
die Einstellungen wieder?
Danke im vorraus!
Gruß nasskapp
