CAN ACK-Error nach IDE-Wechsel (STM32F4)

[Kris (Gast)]

Hallo zusammen, bastele mal wieder mit einem STM32F4 Discovery rum.
Da das aktuelle Projekt aber nicht unbedingt für den Privatgebrauch 
gedacht ist, bin ich hierfür von Atollic True Studio Lite auf CooCox 
CoIDE umgestiegen.

Dabei bin ich auf folgendes Problem gestossen: beim Versuch, meine 
Prototyping-Hardware mit CANalyzer quatschen zu lassen, bekomme ich nur 
ACK-Fehlermeldungen, sobald ich mit CANalyzer etwas sende. Sende ich mit 
dem STM32, kommt nichts an. Auch ein Scan sämtlicher Baudraten bleibt 
ohne Ergebnis. Ich bin mir aber aufgrund bisheriger Erfahrungen mit 
CAN-Anwendungen auf dem STM relativ sicher, dass der eigentlich richtig 
initialisiert sein muss und auch auf 500kBit/s laufen sollte. Die 
altbekannte "CAN-Init hat geklappt"-LED leuchtet auch. Grüble nun schon 
seit einiges Stunden erfolglos rum.

Zumindest einen Hardware-Fehler kann ich auschließen: mit altem 
(Atollic-)Quellcode kommen Nachrichten an. Jetzt also meine Frage:
Fällt einem von euch eine Möglichkeit ein, was beim Wechsel der IDE 
unterschiedlich sein könnte? Offensichtliche Dinge wie die verwendeten 
Librarys oder die CLK-Einstellungen habe ich schon überprüft, aber man 
weiß ja nie, vielleicht hat ja jemand schonmal ähnliche Erfahrungen 
gemacht. Betreibe im Rahmen dieses Projekts auch eine scrollbare 
Menüoberfäche auf einem 4x20-LCD, das funktioniert alles wunderbar, 
deswegen ärgert es mich um so mehr, dass ich hier nicht weiterkomme.

Auch über Tipps zum debuggen freue ich mich, bin zwar (hoffentlich^^) 
kein blutiger Anfänger mehr, aber nicht unbedingt Muttersprachler was C 
angeht. Vielleicht weiß ja jemand, wie ich beispielsweise einen 
eventuellen Errorcode vom CAN-Controller des STM als String auf dem LCD 
ausgeben könnte? Mit printf, itoa u.ä. tue ich mich ehrlich gesagt etwas 
schwer.

Da der Quellcode mittlerweile ziemlich umfangreich ist, im Anhang mal 
nur die CAN-Config. Auf Anfrage gibt's gern Nachschlag.

Danke schon mal im Voraus für kreativen Input!

[Kris (Gast)]

Oh Mann, der Teufel liegt im Detail. Komplette Betriebsblindheit und 12h 
auf Code gestarrt, und dann ist es so ein trivialer Fehler:

  /* Configure CAN RX and TX pins */
  GPIO_InitStructure.GPIO_Pin = GPIO_Pin_0 | GPIO_Pin_1;

Da muss es natürlich GPIO_Pin_0 heißen, nicht GPIO_PinSource0. Da hab 
ich mich wohl beim Portieren der Initialisierung vertan. Und der 
Compiler meckert natürlich nicht...

Außerdem ist in der Vorbereitung der Tx-Message noch die Zeile mit dem 
"i" zuviel, aber das war nicht wirklich das Problem.

Trotzdem Danke an alle, die sich eventuell Gedanken gemacht haben.