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.
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.
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)
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.
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.
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.
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
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.
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...
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
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.
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.
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
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
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?
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?
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.
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.
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.
