STM32F103 & CAN

[Arne (Gast)]

Servus,

habe folgendes Problem mit CAN am STM32F103.
STM ist auf einem Olimexboard, Transceiver ist SN65HVD230. Gegenstelle 
ist ein LPC-Board mit dem selben Transceiver.
Nun lege ich einen Frame in CAN_TDL0R, CAN_TDH0R, CAN_TDT0R und CAN_TI0R 
und setze beim Ablegen des Identifiers in CAN_TI0R das TXRQ-Bit.
Damit signalisiere ich dem STM, dass der Frame vollständig in seine 
Sendemailbox kopiert wurde. Nun sollte der CAN-Controller mit dem Senden 
beginnen, da ja der Bus frei ist.
Macht er aber nicht und nimmt ergo auch nicht das TXRQ Bit zurück. Habe 
CAN_H gegen GND und CAN_L gegen Masse gemessen: ca. 2,3V. Passt auch zum 
Datenblatt des Transceivers.

Der Bus ist m.E. nach frei, aber der STM CAN Controller erkennt dies 
nicht und verweigert somit das Senden. Ist jetzt erstmal meine 
Erklärung.
Hat jemand eine Idee, was ihn vom Senden abhält?

Gruß, Arne

[Heinz-Jürgen O. (Firma: emtas) (hjo)]

Arne,
CAN Controller Takt, sprich Bit Timings programmiert.
Ohne im Datenblatt nachzusehen, geht das Bit erst weg, wenn erfolgreich 
gesendet wurde? Dann muss ein anderer CAN Controller eine korrekt 
empfangene CAN Message bestätigen (ACK).
Du hast ja eine Gegenstelle, ist aber garantiert, dass beide die gleiche 
Bit Rate benutzen?

 Heinz

PS
Und benutzt Du die 'richtigen' CAN Pins zum Transceiver?

[Arne (Gast)]

Moin Heinz-Jürgen,

> Ohne im Datenblatt nachzusehen, geht das Bit erst weg, wenn erfolgreich
> gesendet wurde?
Ja, so steht es im Datenblatt:

24.7.1       Transmission handling
In order to transmit a message, the application must select one empty transmit mailbox, set 
up the identifier, the data length code (DLC) and the data before
requesting the transmission by setting the corresponding TXRQ bit in the
CAN_TIxR register. Once the mailbox has left empty state, the software no
longer has write access to the mailbox registers. Immediately after the
TXRQ bit has been set, the mailbox enters pending state and waits to
become the highest priority mailbox, see Transmit Priority. As soon as the
mailbox has the highest priority it will be scheduled for transmission.
The transmission of the message of the scheduled mailbox will start (enter
transmit state) when the CAN bus becomes idle. Once the mailbox has been
successfully transmitted, it will become empty again. The hardware
indicates a successful transmission by setting the RQCP and TXOK bits in
the CAN_TSR register.

Und

Bit 0  TXRQ: Transmit mailbox request
Set by software to request the transmission for the corresponding mailbox.
Cleared by hardware when the mailbox becomes empty.

Beide Seiten auf 125kbit gestellt. Die Bitratenregister LPC und STM sind 
sogar sehr ählich aufgebaut.
Am Ruhepegel von 2.3V kann der STM ja gar nicht feststellen welche 
Bitrate die Gegenseite benutzt. Fehlerfall kann er ja erst feststellen, 
wenn z.B. niemand das ACK setzt. Es MUSS also was rausgehen, damit ein 
Fehler erkannt werden kann.

> Und benutzt Du die 'richtigen' CAN Pins zum Transceiver?
ist auf beiden Evalboards fest verdrahtet.
Remapping am Olimexboard (STM) auf PB8 und PB9 gestellt. Passt auch 
lt.Schaltplan.

[Arne (Gast)]

Das remapping im AFIO_MAPR hatte ich gemacht, aber vergessen die Pins 8 
& 9 auf PortB auf Input-PullDown bzw. AlternateFunction-PushPull zu 
stellen. Jetzt sehe ich am Oszi wenigstens schon mal die Sendeversuche.

[Heinz-Jürgen O. (Firma: emtas) (hjo)]

Das ist ja schon etwas.
Ich würde zunächst ab dieser Stelle ohne die LPC Gegenstelle arbeiten.
Der CAN Sender versucht dann ständig das angewiesene Telegramm zu 
senden,
da er kein ACK bekommt.
Das lässt sich prima auf dem Oszi sehen und es lässt sich auch die Bit 
Zeit einigermassen gut auslesen, wenn du zum Beispiel eine ID 0x555 
nimmst und auch die Datenbytes mit 0x55.

Viel Erfolg
 Heinz

[Arne (Gast)]

Die Richtung STM->LPC tut. Jetzt noch die umgekehrte Richtung.