stm32f103 CAN-Interface

[Roland H. (blacksmoke)]

Hallo Zusammen,

Ich versuche aktuelle mal ein CAN-Interface mit dem stm32f103 auf die 
Reihe zu bekommen. Generell verwende ich die StdPeripheral-Library. mein 
STM läuft mit 24MHz und externem Quartz. Der Can soll erst mal mit 125 
kHz laufen.

Angschlossen habe ich an Port A11/A12 einen tja1050 und am anderen Ende 
einen CAN-USB-adapter/ Logic-Analyzer.

Leider bekomme ich nur im Sendetakt einen kurzen Impuls und mehr 
passiert nicht. Der Impuls kommt alle Sekunde. Das Programm läuft aber 
weiter (das sehe ich an der LED und am Uart)

Falls ich Angaben vergessen habe, gerne nachfragen.

Nun hoffe ich auf das Schwarmwissen hier um evtl. fehler in meiner 
Initialisierung, ... aufzudecken. An Abschlusswiderstände hab ich 
natürlich gedacht.

[Carl D. (jcw2)]

Roland H. schrieb:
> An Abschlusswiderstände hab ich natürlich gedacht.

Wobei das Meßergebnis, wenn man die Innenschaltubg des Treiber sieht, 
genau zu "kein Abschluß-Widerstand" passen würde.
Vielleicht ist er ja schlicht "nicht wirksam".

Edit: der LA hat sicher Pull-Ups, die CANL auch sauber auf Löw zieht.

[Bastian W. (jackfrost)]

Mim Saleae soll man an CAN Recive oder wenn das nicht geht an CANH 
messen. Wo hast du ihn drann ?

Gruß JackFrost

[Roland H. (blacksmoke)]

Ich habe an beiden seiten schon gemessen, das Ergebniss ist recht 
Ähnlich. Initialisierung is auch die Frage ob das alles so richtig ist. 
Ich glaube die Angaben für Quanten, habe ich aus einem kleinen 
onlinetool berechnen lassen.

ach ja noch folgende uart-Ausgabe dazu.

Can-Status ist dabei der Rückgabewert von CAN_Transmit. Ich deute das 
als Versuche zu senden wobei er irgendwann aufgibt


#define CAN_TxStatus_Failed         ((uint8_t)0x00)/*!< CAN transmission 
failed */
#define CAN_TxStatus_Ok             ((uint8_t)0x01) /*!< CAN 
transmission succeeded */
#define CAN_TxStatus_Pending        ((uint8_t)0x02) /*!< CAN 
transmission pending */
#define CAN_TxStatus_NoMailBox      ((uint8_t)0x04) /*!< CAN cell did 
not provide an empty mailbox */

(Auszug aus stm32f10x_can.h)

[Gerd E. (robberknight)]

Hast Du Dir die Signale mal mit dem Oszi angeschaut?

Gerade wenn das Ergebnis im Logic Analyzer so unerwartet aussieht, würde 
ich erst mal sicherstellen, daß das kein Messfehler des Logic Analyzers 
ist und der einfach nur mit dem differentiellen Signal nicht klar kommt.

Das der Controller nach einer Weile des Sendens von sich aus aufgibt ist 
in diesem Szenario ganz normal: es fehlt ein weiterer Busteilnehmer, der 
ACKs setzt.

[Roland H. (blacksmoke)]

mit dem Oszi könnte ich die Tage mal messen ja. kann gut sein, dass ich 
am Analyzer nur irgendwas interpretiertes sehe. Als zweiten 
Busteilnehmer habe ich einen USB-CAN-Adapter. Dieser Part wird also 
durch meinen Rechner übernommen.

[Gerd E. (robberknight)]

Roland H. schrieb:
> mit dem Oszi könnte ich die Tage mal messen ja. kann gut sein, dass ich
> am Analyzer nur irgendwas interpretiertes sehe.

eher Probleme mit den Buspegeln als eine "Interpretation".

Alternativ könntest Du statt den Logic Analyzer direkt an CAN-H/-L zu 
hängen, einen CAN-Transceiver nehmen und den Logic Analyzer an den 
R-Ausgang des Transceivers hängen. Dann bekommt der Logic Analyzer 
saubere Logikpegel.

> Als zweiten
> Busteilnehmer habe ich einen USB-CAN-Adapter. Dieser Part wird also
> durch meinen Rechner übernommen.

Vielleicht ist der nicht richtig konfiguriert oder ist in einem 
Nur-Zuhören-Modus, in dem er keine ACKs setzt.

[Bastian W. (jackfrost)]

Ich hab bei mir mal an CAN gemessen. Ich nutze für die Transreciever nur 
3,3V. Am CANH kann der Saleae nichts erkennen ( braun). An CANL (rot) 
wird was erkannt aber es stimmt nicht immer mit dem Frame überein. An 
CANR (schwarz) kommen die Nachrichten richtig an.
Anbei ist noch das Oszillogramm.
Das läuft auf einem STM32F107 mit einem SN65HVD230 Transreciever.


Gruß JackFrost

[Roland H. (blacksmoke)]

Vom Messen werd ich halt trotzdem schwer auf das Problem schließen 
können vermutlich. Wenn  ich annehme, dass meine Initialisierung richtig 
ist, bleiben noch ein Paar sachen:

- Zweiter Busteilnehmer nicht vorhanden oder sendet kein ACK
- Fehlende Abschlusswiderstände
- Pegelprobleme ?

In irgend einer weiße an der Schaltung. Allerding habe ich das Probleme 
vor und nach dem Transceiver gleichermaßen. Meinen USB-Can-Adapter 
initialisiere ich mit 125khz und lasse candump laufen. Das sollte 
eigentlich schon funktionieren vermute ich (sicher bin ich mir dessen 
aber nicht. Ich habe allerdings den Sourcecode zu diesem hier) Aber das 
kann ich trotzem mal checken, ob dieser evtl nur zuhört.

[temp (Gast)]

Roland H. schrieb:
> Vom Messen werd ich halt trotzdem schwer auf das Problem schließen
> können vermutlich. Wenn  ich annehme, dass meine Initialisierung richtig
> ist, bleiben noch ein Paar sachen:
>
> - Zweiter Busteilnehmer nicht vorhanden oder sendet kein ACK
> - Fehlende Abschlusswiderstände
> - Pegelprobleme ?
>
> In irgend einer weiße an der Schaltung. Allerding habe ich das Probleme
> vor und nach dem Transceiver gleichermaßen.

Im ersten Schritt brauchst du überhaupt keinen weiteren Teilnehmer. Häng 
deinen Saleae an den CanTx vor den Transceiver. Wenn deine 
Initialisierung richtig war muss da der Versuch des Sendens zu messen 
sein, und am CanRx sollte das gleiche zu messen sein wenn der 
Transceiver geht. Normalerweise endet das sogar im Dauerfeuer wenn kein 
ACK von einem Teilnehmer kommt.
Sollte das nicht geholfen haben, musst du wohl systematisch vorgehen. 
Das heißt, Manual vom µC nehmen und mit dem Debugger die Register 
kontrollieren ob das was man sich ausgedacht hat da auch drin steht. Ach 
ja, ich vergaß, das braucht man ja alles nicht wenn man HAL o.ä. 
verwendet. Da fragt man lieber mal im Forum nach...

[Roland H. (blacksmoke)]

Ich verwende absichtlich nicht die HAL, weil mir das einfach viel zu 
sehr Abstrahiert ist und auch teilweise Sachen nicht so funktionieren 
wie gewünscht. Deshalb bin ich eher dazu geneigt die alte StdPheriph-lib 
zu verwenden oder (was ich auch schon gemacht hab mit Timer glaub ich) 
mich durch das manual zu wühlen und die Register wie früher selbst zu 
beschreiben. Ich habe eigentlich mit AVR angefangen. Dort war das noch 
so und man hat einfach gewusst woran man ist. Vor ein paar Jahren bin 
ich dann zu STM, weil die einfach sehr viele Features fürs geld bieten 
und man landet dort relativ schnell mitlerweile bei HAL (als ich im 
Studium angefangen hatte war es eben noch die Std-Pheripheral). Deshalb 
habe ich vor einigen Wochen mal angefangen, meine Standardlibs auf diese 
wieder umzustellen (was auch schneller ging als gedacht). Und siehe da 
es war auf einmal wieder viel übersichtlicher und man hat sich wieder 
viel mehr mit dem uC selbst befasst als sich durch die HAL zu wühlen.

So nun zurück zu meinem Problem:

Wenn du sagst, dass eigentlich trotzdem zumindest der Versuch einer 
Nachricht zu sehen sein sollte (unabhängig davon ob Terminierung oder 2. 
Busteilnehmer vorhanden ist) dann hätte ich auch eher vermutet, dass es 
auf der uC-Seite liegen müsste. Kann ja sein, dass dem ein oder anderem 
ein offensichtliches Problem oder so an der Initialisierung aufgefallen 
ist

[Simi S. (kokoianer)]

Hallo Zusammen

Ich hatte auch schon CAN auf einem STM32 programmiert und es hat 
funktioniert...

Folgende Seite war mir sehr hilfreich.

http://diller-technologies.de/stm32.html#can

Gruss

[Johannes S. (Gast)]

ich habe das CAN Interface am Sonntag in kurzer Zeit mit mbed auf dem 
Bluepill und einem LPC11C24 als Gegner zum Laufen bekommen: 
https://os.mbed.com/docs/v5.10/apis/can.html
mbed-cli installieren, ein Projekt mit ein paar Befehlen anlegen und das 
Beispiel importieren, eine Sache von ein paar Minuten.
Beim LPC11C24 war nur ein Jumper mit H/L nicht im Schaltplan und blöd 
beschriftet, da hatte ich zuerst H/L vertauscht, da ging auch nichts.
Das Rigol Oszi habe ich auch, mit der 'Math' Taste kann man noch das 
Differenzsignal bilden lassen. Bei Bastian sehen die Pegel asymmetrisch 
aus, ist das richtig? Bei mir war das schön symmetrisch.

[Lutz (Gast)]

temp schrieb:
> Normalerweise endet das sogar im Dauerfeuer wenn kein
> ACK von einem Teilnehmer kommt.

Nein, erst müßte error passive und dann bus off folgen, damit der Bus 
nicht von einem Amokläufer lahmgelegt wird.

[Bastian W. (jackfrost)]

Johannes S. schrieb:
Bei Bastian sehen die Pegel asymmetrisch
> aus, ist das richtig? Bei mir war das schön symmetrisch.

Ich glaube das bei dem Kniten bei dem die Biaswiderstände aktiv sind was 
nicht passt. Daher dürfte der Ruhepegel nich auf VCC/2 liegen.

Gruß JackFrost

[Roland H. (blacksmoke)]

Mit dem oszi sieht das leider ganz ähnlich aus. Ich muss mich wohl erst 
mal durch das Manual wälzen. Hab leider noch immer keine Ahnung woran es 
liegen könnte. Hab nochmal die Schaltung kontrolliert. So ganz ohne 
anderen Busteilnehmer sieht es genauso aus. Ich habe mal versucht von 
der anderen Seite was zu senden und gehofft ich würde nach dem 
transseiver irgendwas sehen, aber ebenfalls fehlanzeige

[temp (Gast)]

Johannes S. schrieb:
> ich habe das CAN Interface am Sonntag in kurzer Zeit mit mbed auf dem
> Bluepill und einem LPC11C24 als Gegner zum Laufen bekommen:
> https://os.mbed.com/docs/v5.10/apis/can.html
> mbed-cli installieren, ein Projekt mit ein paar Befehlen anlegen und das
> Beispiel importieren, eine Sache von ein paar Minuten.

Und wenn es zufälligerweise nicht funktioniert hätte, würden wir hier 
das gleiche Rumgeeiere lesen?

[Gerd E. (robberknight)]

Roland H. schrieb:
> Mit dem oszi sieht das leider ganz ähnlich aus. Ich muss mich wohl erst
> mal durch das Manual wälzen. Hab leider noch immer keine Ahnung woran es
> liegen könnte. Hab nochmal die Schaltung kontrolliert. So ganz ohne
> anderen Busteilnehmer sieht es genauso aus.

Ich würde als erstes mal versuchen herauszufinden, ob es an der 
Schaltung, Verkabelung oder an der Programmierung liegt.

Nimm mal einen anderen µC (nicht daß Dein Exemplar schon teilweise 
kaputt ist) und nicht in die CAN-Schaltung eingebaut, z.B. auf einem 
freien Breakout-, Discovery- oder Bluepill-Board. Häng Deinen Logic 
Analyzer an CAN-TX des Controllers und verbinde es mit nichts anderem. 
Starte Dein Sende-Programm. Was kommt dann? Sieht das mehr nach CAN aus 
als das Bild im ersten Post?

[M. Н. (Gast)]

Lutz schrieb:
> temp schrieb:
>> Normalerweise endet das sogar im Dauerfeuer wenn kein
>> ACK von einem Teilnehmer kommt.
>
> Nein, erst müßte error passive und dann bus off folgen, damit der Bus
> nicht von einem Amokläufer lahmgelegt wird.

Falsch. Wenn dein CAN keine Gegenstelle hat, aber sein eigenes Signal 
korrekt zurückließt, geht er auf Dauerfeuer. Das führt nie zu einer 
Abschaltung.

Der Grund dahinter ist der Boot-up von Netzwerken. Wenn deine Geräte am 
Bus hochfahren und eins sendet, während alle anderen noch nicht bereit 
sind, würde sich das Gerät nach einigen Frames abschalten. Es würde 
somit einen leeren Bus als Fehler erkennen. Stattdessen sendet es aber 
so lange, bis es entweder einen echten Fehler (TX != RX) selbst 
feststellt oder ein ACK/Error bekommt.

Man kann somit den CAN auch ohne transceiver testen, indem man RX und TX 
verbindet und dann eine Message sendet. Der CAN geht dann auf Dauerfeuer 
und das Frame kann mittels Logicanalyzer, Oszi angeschaut werden.

Wenn ein Transceiver angeschlossen ist, muss der Terminierungswiderstand 
angeschlossen sein. Am bestne beide. Das liegt daran, dass der CAN 
Transceiver (Zumindest alle, die ich hier habe) die Pegel der CANH und 
CANL Leitungen nur richtig anfährt, wenn eine Ohm'sche Verbindung 
zwischen CANH und CANL ist. Den genauen Grund dafür kenne ich selbst 
gerade nicht. Aber ein CAN funktioniert ohne Widerstand bei mir nicht.

[Roland H. (blacksmoke)]

also wenn ich rx und tx vom uC verbinde sieht es am Oszi tatsächlich 
nach Daten aus. Der Logicanalyzer sagt das es die Daten sind die ich 
sende. Also liegt es eher nicht auf der uC-Seite sonern an der Schaltung 
dahinter.

[Roland H. (blacksmoke)]

Ich habe nun den tja1050 gegen einen sn65hvd230 getauscht und jeweils 
120 Ohm an jedes Ende und siehe da, es funktioniert. Mich würde 
allerdings interessieren was der tja1050 für Probleme dabei macht.

[Roland H. (blacksmoke)]

ok die vermutliche Auflösung davon ist, dass der tja1050 zwar 3.3V und 
5V pegel akzeptiert, aber VCC trotzdem 5V haben will.