Moin moin, hat es schonmal jemand geschafft einen CAN FD auf den CortexM-7 Prozessoren von Atmel zum laufen zu bringen? Der Treiber ist fehlerhaft, aber auch wenn man die Fehler korrigiert und die Register-Werte alle korrekt aussehen, kommen nur normale CAN-Frames (Mit einem DLC von >8) raus. Weder werden die zusätzlichen Bytes gesendet, noch ändert sich die Taktrate nach dem BitRateSwitch. Wenn ich die Doku richtig lese müssen für ein CAN FD Frame im CCCR-Register FDOE und BRS gesetzt sein. Im TX-Buffer muss FDF und BRS gesetzt sein. Ist in allen Registern korrekt drin, aber trotzdem kein FD-Frame? Das Bit für Non-ISO-FD kann man gleich mal gar nicht setzen.. Ideen?
Gast
#5123086
Welchen Treiber meinst du? Es gibt das alte softpack für bare metal Entwicklung, die alte asf3 ausm Studio und das neue asf4 im atmel start...
Ich hab sowohl den alten treiber aus dem ASF probiert, als auch den neuen aus Atmel Start. Beide haben aber das gleiche Problem, dass die FDOE und BRS im CCCR-Register nicht setzten. Außerdem enthält die can_message struct keinen Parameter für CAN FD. Die Stellen im Treiber hab ich angepasst so dass im MCAN_CCCR Register am Ende 0x0000 0300 steht. Das heißt BRSE und FDOE sind auf 1 Im TX-Buffer steht: 0x0004 0000 0x003c 0000 ... ... Was Wohl ID 4, FDF==1 BRS==1 entspricht. Wenn ich an der ID, den Daten oder am DLC im Debugger rumpfusche sehe ich die Änderungen sofort im Bus. FDF und BRS haben aber keinen Einfluss auf die Botschaft.
Gast
#5123572
Hm ich habe das softpack mal verwendet und mich an die bsp programme gehalten. Sowas hatte ich nicht. Can-fd auf einem automotive bauteil würd ich eher über support auf microchip.com suchen es gibt da einen Dominik der relativ flix drauf antwortet. Glaub nicht dass du hier nw Lösung findest, die Thematik ist zu speziell
Das Problem ist gelöst. Es gibt verschiedene HW-Revisionen von dem Chip. die komplette Doku und die Treiber beziehen sich auf die neue. ACHTUNG: Die üblichen Verdächtigen verkaufen nach wie vor das Eval-Baord mit der Rev. A