stm32 und can

Beitrag "CAN Baudrate - Erfahrungswerte"

Danke Jungs, der Beitrag "CAN Baudrate - Erfahrungswerte" ist mir 
inzwischen auch aufgefallen. da kämpf ich mich jetzt grad mal durch.

OK, so einigermaßen habe ich das jetzt mit dem Timing geschnallt. Da 
muss ich aber schon nochmal nachhaken.
Aber mal abgesehen davon müsste doch auch, wenn das nicht richtig 
eingestellt ist auch was rauskommen oder? Dann liegt mein Fehler wohl 
schon viel früher. Also hier mal mein Programmablauf:

ich remape CAN1 und initiolisiere die entsprechenden GPIOs
anschließend initialisier ich folgendermaßen:

void CanInit()
{
  pCAN->MCR   = 0x00000001;         //Initialisierungsmodus

  while (!(pCAN->MSR & 0x00000001)) //weiter wenn Initialisierungsmodus
  {
  }


  pCAN->BTR   = 0x02440030;         //normaloperation,SJW=2,TS2=TS1=4;
                                      Baudrate=1000000
  pCAN->MCR  |= 0x00000014;     //nur einmal 
senden;Priorität=chronologisch

  pCAN->MCR   = 0x00000014;         //normaler Modus

   while (!(pCAN->MSR & 0x00000C00))//weiter wenn normaler Modus
  {
  }
}

hier schonmal ein sorry an alle die das lieber mit Namen sehen, aber 
finde das mit Hex und Komentaren übersichtlicher.

bis hierhin passiert erstmal nichts auf der Leitung. Führe ich 
allerdings meine senden-Funktion aus springt das Signal auf 0 und rührt 
sich nicht mehr.

void CanSend()
{
  pCAN->TDT0R = 0x00000001;         //1 Datenbyte
  pCAN->TDL0R = 0x00000024;         //Daten
  pCAN->TI0R  = 0x00000001;         //senden

  while (!(pCAN->TSR & 0x04000002))//weiter wenn normaler Modus
  {
  }
}

Hat da vielleicht einer ne Idee dazu? Filter hab ich auch erstmal 
weggelassen.

Oder wie läuft das mit dieser Initialisierung? Ich hab auf der anderen 
Seite einen Dongle von Peak und deren Software Namens PCAN-View. Aber 
bewegen tut sich da garnichts auf der Leitung.

> hier schonmal ein sorry an alle die das lieber mit Namen sehen, aber
> finde das mit Hex und Komentaren übersichtlicher.

Tja... Kaum jemand macht sich die Mühe, fremden Quellcode zu 
analysieren, dessen Registerinhalte von Steuerregistern mit allerlei 
Einzelbits und Bitfeldern summarisch in Hex als 0x12345678 geschrieben 
werden. Es sei denn er wird dafür bezahlt.

Kommentare sind dabei wertlos, weil weder für Compiler noch für Maschine 
rechtsverbindlich und weil nicht selten falsch.

Aber wenn da nur Namen stehen weiß immer noch keiner ob da hinten dran 
die richtigen Bits gesetzt. werden.
OK, dann hier mal mein Ablauf ist der wenigstens Korekt oder hab ich was 
vergessen?

ich remape CAN1 und initiolisiere die entsprechenden GPIOs
->Initialisierungsmodus
-> BTR einstellen
-> MCR -> nur einmal senden; Priorität = chronologisch
-> normalerv Modus
-> TDT0R -> Länge einstellen
-> TDL0R -> Daten in Mailbox schreiben
-> TI0R -> TXRQ setzen

Abschlüsse dran?

Der Dongle ist wahrscheinlich passiv, d.h. er quittiert nicht. Damit 
läuft der Controller in nullkommanix auf Fehler.

Probier für den Anfang mal den Loopback-Modus, und zwar den aktiven, 
d.h. LBKM ohne SILM.

aber ich müsste doch erstmal was auf der Datenleitung sehen, oder nicht? 
Hab ein Oszi dran, aber es kommt garnichts raus. nicht ein Bit. Der 
springt nur von High (Ruhepegel) auf Low. weiter nichts.

Hat die CAN-Unit einen Takt?

wie erwartet. mit loop back ist es das gleiche spielchen.

nochmal zu meinem sendevorgang:

TDT0R einstellen
Daten ins TDL0R
TI0R setzten


stimmt das? mir ist grad noch das RF0R-Register aufgefallen. was ist mit 
dem RFOM0?

sollte, aber du hast recht. das hab ich noch nicht überprüft. das mach 
ich direkt?

schade, das wäre ja auch zu einfach gewesen. aber ich setzte im 
RCC-APB1ENR das entsprechende Bit. So einen Taktausgang wie bei der 
USART gibts ja hier leider nicht? sonst könnte ich das auch mal 
messtechnis´ch überprüfen.

Steht etwas im ESR?

nein, nur 0x00000000. aber bei der Gelegenheit fällt mir auf, dass das 
Problem vermutlich an meinem Initialisierungsmodus liegt. Da schein was 
nicht zu klappen. im MCR steht nämlich noch der resetzustand. da muss 
ich wohl nochmal nachhacken

Schon mal vorher einen Reset probiert?

Komando zurück. das war wohl ein Fehler von mir. MCR und BTR werden 
korekt initialisiert und das ESR ist und bleibt auf Null. Ich vermute 
jetzt mal, dass das Problem an meiner Verbindung zum PC und dem 
PCAN-Dongle liegt. Wie läuft denn das mit der Initialisierung vor dem 
senden? Da muss doch vermutlich eine Kommunikation auf laufen. Bei mir 
ist da nur Stille. Kann das mein Problem sein?

mit Reset zeigt sich das gleiche Bild

Ben Nor schrieb:

> jetzt mal, dass das Problem an meiner Verbindung zum PC und dem
> PCAN-Dongle liegt.

Im Loop-Mode ist die egal.

Aber tu dir und mir mal den Gefallen und dekodiere alle aufgeführten 
Bits in der Initialisierung. Notfalls daneben schreiben.

welche Initialisierung meinst du? den Initialisierungmodus oder das vor 
dem senden der daten?

Die Funktion.

Gut, ich glaube ich hab den Knackpunkt gefunden. Laut MSR sind sind 
SLAKI und INAK dauerhaft gesetzt und ich bin somit im Schlaf- und 
Initialisierungsmodus gleichzeitig. Keine Ahnung warum er dann die ganze 
Zeit überhaupt aus der Funktion rausgesprungen ist. Habe jetzt ne kleine 
Wartezeit eingebaut und jetzt hängt er an meiner while-Schleife fest. In 
dieser Schleife setzte ich jetzt im MCR das INRQ dauerhaft zurück und es 
passiert nichts. Ganz komisch finde ich das. SLKI und INAK gleichzeitig 
geht das überhaupt?

Keine Ahnung. Aber wie wär's mit meinem Vorschlag?

bin ich nochmal durchgegangen und ich finde einfach keinen fehler 
irgendwo ist aber der wurm drin. aber da muss ich jetzt halt nochmal 
durchgehen.

aber danke soweit für deine hilfe. das ist garantiert irgend ein kleiner 
scheiß. früher oder später find ich den garantiert. genau aus solchen 
gründen mach ich lieber hard- als software.

Wer sich nicht helfen lässt, der muss eben selber sehen wo er bleibt.