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.
Hallo Holger, welche .dip File Version verwendest Du für den XE167 und auf welcher Frequenz arbeitest Du?
Hallo Tannenzaepfle, ich arbeite mit der DIP-Version 2.1. Die Systemfrequenz des XE167 beträgt 66 MHz bei einem externen 8 MHz Quarz. Gruß Holger
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.