Hallo Zusammen,
ich versuche momentan eine CAN-FD Kommunikation aufzubauen und scheitere
bei hohen Baudraten. Eventuell hat ja hier noch jemand Erfahrung mit den
verwendeten Chips und kann helfen.
Folgendes Problem:
Auf der Platine befinden sich ein XMega, der CAN-FD-Controler MCP2517FD
und der CAN-FD Transceiver MCP2562FD. Die normale Kommunikation mit
CAN2.0 läuft problemlos. Auch die CAN-FD Kommunikation mit einer
Nominal-Bitrate von 1MBaud und der Daten-Bitrate von 2MBaud
funktioniert. Signale sehen am Oszi ebenfalls sauber aus.
Nun wollte ich aber die maximale Baudraten der Daten auf 8MBaud
hochschrauben, musste dabei aber feststellen das nichts mehr geht. Nach
einigem Suchen und Probieren sind folgende Erkenntnisse gewonnen:
CAN-FD funktioniert bis knapp über 2MBaud Daten-Bitrate, anschließend
wird beim Senden einer Nachricht kurz nach dem Bitrate-Swich-Bit
abgebrochen. So wie bisher beobachtet, werden nach dem
Bitrate-Switch-Bit noch das ESI Bit und zwei Bits des Data-Length-Code
(DLC) übertragen. Danach bleibt das CAN-High Signal auf "high".
Wenn man das Diagnoseregister des CAN-FD Controlers ausliest, sind zwei
Bits mit folgender Bedeutung gesetzt:
Bit 1:
During the transmission of a message (with the exception of
the arbitration field), the device wanted to send a recessive
level (bit of logical value '1’), but the monitored bus value
was dominant.
Bit 2:
During the transmission of a message (or acknow ledge bit, or active
error flag, or overload flag), the device wanted to send a
dominant level (data or identifier bit logical value ‘0’), but
the monitored bus value was recessive.
Nun wäre ich über Hinweise und Lösungen dankbar, wie ich die Bitrate im
Datenbereich der CAN-FD Nachrichten erhöhen kann und das ganze noch
weiterhin funktioniert. Oder können die aktuellen Chips evtl. gar nicht
mehr als 2MBaud??!?
Viele Grüße,
Fabian
Flyget schrieb:> Oder können die aktuellen Chips evtl. gar nicht mehr als 2MBaud??!?
Jedenfalls scheint das Transceiver Datenblatt das so zu sehen. Was nicht
heisst, das 8MBaud generell nicht geht mit passendem Bus (Länge,
Verzweigungen, Teilnehmerzahl, ...).
http://ww1.microchip.com/downloads/en/DeviceDoc/20005284A.pdf
Seite 1:
"Meets or exceeds stringent automotive design requirements (...) @
2Mbps "
Seite 3:
"The Loop Delay Symmetry is guaranteed to support data rates
that are up to 5 Mbps for CAN FD (Flexible Data rate). The maximum
propagation delay was improved to support longer bus length."
Flyget schrieb:> Diagnoseregister des CAN-FD Controlers ausliest, sind zwei> Bits mit folgender Bedeutung gesetzt:> Bit 1:> During the transmission of a message (with the exception of> the arbitration field), the device wanted to send a recessive> level (bit of logical value '1’), but the monitored bus value> was dominant.
Das klingt doch ein wenig danach, als ob dein Bus das AC Timing für
"Recessive bit time on RXD" bei 8 Mbps nicht schafft und durch das loop
delay verspätet am RXD einliest was am TXD gesendet wird(wurde?).
Seite 13 (AC spec)
"t_BIT(RXD),8M Recessive bit time on RXD - 8 Mbps, Loop Delay Symmetry
min 85/typ 105/max 140 ns
see Figure 2-10 -> Note: The bit time of a recessive bit after five
dominant bits is measured on the RXD pin. Due to asymmetry of the loop
delay, and the CAN transceiver not being a push pull driver, the
recessive bits tend to shorten."
Du kannst davon ausgehen, dass die Chips mehr als 2 MBaud können.
Wenn die Hersteller die Bauteile für nicht mehr bewerben, heißt das,
dass die Hersteller bei den üblichen Zertifizierungen irgendwo bei den
EMV Tests durchgefallen sind wegen zu viel Abstrahlung oder DPI test
nicht bestanden etc...
8 MBaud ist schon sehr schnell.
Hast du mal geschaut, ob du nicht evtl. Probleme mit Ringing auf der
Leitung hast?
Hallo und schonmal vielen Dank für die Antworten!
Nach Klingeln sieht mir das ganze nicht aus. Klar sieht das Signal nicht
aus wie ein im CAD gezeichnetes Rechteck, aber doch brauchbar. Zur
Verdeutlichung gibts Bilder im Anhang. Inzwischen ist auch die
Differenzdrossel und die 2x 100pF am CAN-Bus entfernt. Optisch hat sich
hier aber signaltechnisch nicht nennenswert etwas verändert... etwas
steiler geworden natürlich.
Zur Erklärung:
- Blau -> CAN-High (ohne Differenzdrossel und Kondensatoren)
- Gelb -> TX
- Lila -> RX
Was das Datenblatt angeht, sehe ich das ähnlich wie Robert, eigentlich
sollte es trotzdem bei den höheren Frequenzen funktionieren. Die
offiziellen CAN-Standards und irgendwelche EMV-Richtlinien werden dann
zwar evtl. nicht mehr eingehalten, aber für den "nicht
Automotive"-Bereich funktioniert es ja normal trotzdem.
Ich hab in den Bildern im Anhang mal die Zeiten rausgemessen. Zwischen
2MBaud und 4MBaud ändert sich da nicht wirklich etwas. Bei 4MBaud is es
natürlich nur insgesamt zeitkritischer bevor das nächste Bit kommt.
Allerdings gibt es ja vmtl. kaum ne Chance das Timing des Chips zu
beeinflussen, was wiederrum bedeuten würde, dass er nicht schneller als
2MBaud läuft...
Weitere interessante Feststellung: Ich vermute der CAN-Controler ist das
Problem, da selbst bei dessen Loopback-Mode die Sache nur bis 2MBaud
funktioniert. Und da is ja der CAN-Transceiver nicht involviert.
Flyget schrieb:> Weitere interessante Feststellung: Ich vermute der CAN-Controler ist das> Problem, da selbst bei dessen Loopback-Mode die Sache nur bis 2MBaud> funktioniert. Und da is ja der CAN-Transceiver nicht involviert.
Interessant. Ist beim Loopback-Mode (internal-/external-loopback) ein
RXD-Eingangsfilter aktiviert? Nicht der Message-Filter, ich meine ein
Filter gegen Glitches auf der RXD-Leitung.
Der TFILTER (T00Filter .. T11Filter im WFT<1:0> bit) scheint nur
relevant fürs Wake-up. Zitat: "The module can be programmed to apply a
low-pass filter to the RXCAN pin while in Sleep mode. This feature
can be used to protect the module from wake-up due to short
glitches on the RXCAN pin."
Der Edge Filter (EDGFLTEN bit) könnte das Problem sein.
Schalte den doch mal ab. Wenn das Loopback dann immer noch nicht geht,
schaue dir die Clock Einstellungen mit Bezug auf den Abtastzeitpunkt an.
siehe dazu:
- MCP2517FD Bit Time Calculations
http://ww1.microchip.com/downloads/en/DeviceDoc/MCP2517FD%20Bit%20Time%20Calculations%20-%20UG.xlsx
- http://ww1.microchip.com/downloads/en/DeviceDoc/20005678A.pdf
Wenn du es hinbekommst den ext. CAN-FD Controller mit 8 Mbps zum laufen
zu bringen, würde ich mich freuen zu erfahren welche reale Datenrate du
mit dem hinbekommst. Denn an deinem µC ist der CAN-FD Controller nur mit
20 Mbps (SPI 20MHz) angeschlossen.
Ich kenne mich mit deinem verwendeten Controller nicht aus. Bei sehr
hohen Baudraten ändert sich der bitzustand auf dem Bus so langsam, dass
der CAN Core noch das vorherige Bit sieht und deshalb abbricht. Durch
eine delay compensation wird das Rücklesen der Bits verzögert, sodass
das wieder passt.
Gibt es eine solche Kompensation bei deinem Controller? Der bosch M_CAN
verfügt bspw. über ein solches Register, da es bei hohen Datenraten
häufig zu Problemen kommen kann, wenn diese nicht aktiv ist. Probleme
können natürlich auch aus anderen Faktoren im Bittiming entstehen
(Sample Point ungünsitg gewählt etc.)
Hier noch ein wenig Lektüre:
https://www.can-cia.org/fileadmin/resources/documents/proceedings/2013_hartwich_v2.pdf
Hallo Flyget,
ich benutze auch den MCP2517FD, bekomme aber nicht den Empfang mit
dem FIFO_CH2 hin. Kannst Du mir einen Tip oder Deine
Receive-Einstellungen
mitteilen? Im FIFOSTA kommt nicht das Signal TFNRFNIF.
alternative: p.palme@t-online.de
