CAN-FD mit MCP2517fd und MCP2562FD bei hohen Baudraten

[Flyget (Gast)]

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

[void (Gast)]

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."

[Robert (Gast)]

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?

[Flyget (Gast)]

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.

[void (Gast)]

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.

[M. Н. (Gast)]

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

[Peter (Gast)]

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: [e-mail]