Hallo! Hat hier jemand Erfahrung mit der Ansteuerung des Can-Busses unter Linux? Ich habe die Schaltung im Anhang an einem Linux-Entwicklungsboard. Wenn ich die CAN-Eingangssignale mit einem Oszilloskop anschaue sieht alles gut aus. Beim Booten des Boards wird vom Treiber geprüft, ob ein MCP2515 am SPI-Bus erkannt wird. Ist erfolgreich. Dann konfiguriere ich das das can0 Netzwerk: ip link set can0 type can bitrate 500000 Sobald ich es starte (ifconfig can0 up), sehe ich kurz SPI-Kommunikation zwischen Prozessor und MCP2515, während der Chip scheinbar resettet und konfiguriert wird, danach überhaupt keine Kommunikation mehr, weder SPI- noch CAN-Signale. Nirgends. Ich kann nichts nichts empfangen und sehe mit dem Oszilloskop nirgendwo Buskommunikation. Obwohl ein CAN-Signal anliegt, ist nicht einmal mehr das zu sehen. Sobald ich "ifconfig can0 down" ausführe, ist wieder Kommunikation sichtbar. Aber ich kann eben can0 nicht verwenden... Was kann da schief laufen? Fehler in der Schaltung? Treiberproblem (der ist im Linuxkernel integriert...). Ich bin ziemlich ratlos und hoffe ihr habt eine Idee, was da schief laufen könnte? Danke :) PS. Die Spannungsversorgung ist 5V, nicht wie oben behauptet 3.3V.
Angehängte Dateien:
-
Bildschirmfoto-2.png
7,1 KB
Oh, dafür gibt es Treiber, super und danke für den Hinweis. Google spuckte diese Seite aus, vieleicht hilft die weiter: http://lnxpps.de/rpie/
Dann weiss ich auch nicht weiter. Ich schliesse meine CAN-Transceiver immer genau anders herum an - und die funktionieren. Diese Anschlussweise ist also falsch, obwohl sie funktioniert. Deine funktioniert nicht, ist aber richtig. Nagut. Ok, vielleicht ist der MCP2551 anders, ich nehme immer 82C250 oder 251.
Test schrieb: > Oh, dafür gibt es Treiber, super und danke für den Hinweis. > > Google spuckte diese Seite aus, vieleicht hilft die weiter: > http://lnxpps.de/rpie/ Vorsicht. Der Schaltplan ist auch falsch :-) Dank Wurststulle endlich aufgeklärt!
Hää?! Ich lass mich gerne eines besseren belehren. Die Schaltung oben und das Datenblatt geben aber mir recht. TX ist mit TX, RX mit RX verbunden. Datenblatt: MCP2515 RX: Receive input pin from CAN bus MCP2551 RX: is usually connected to the receiver data input of the CAN controller device
Tx mit Tx und Rx mit Rx is ja auch korrekt. Allerdings liegt Tx vom 2515 auf Pin1, Rx auf Pin2. Das ist das eben der Preis, den man für die dämliche Darstellungsweise als DIL-IC zahlt und Leitungen nach Belieben anschliessen und benennen kann.
Ok, wir sind uns einig - TX ist mit TX und RX mit RX verdrahtet. Daran liegts also nicht. Danke für den Hinweis mit der Skizze.
Hast du es in echt korrekt verdrahtet (1->1 und 2->4) oder wie in deiner Skizze (1->4 und 2->1)? D.h. nur der Schaltplan war falsch?
Nur der Schaltplan war falsch, korrekt verdrahtet. Sorry.
Angehängte Dateien:
-
Bildschirmfoto-3.png
6,7 KB
Hier der geänderte Schaltplan, das Problem besteht immer noch... Andere Ideen wie es zu diesem Problem kommen kann?
Wenn da nix mehr tut, wenn du can0 auf enable setzst, dann prüfe mal die CS-Leitung, nicht dass die active LOW ist und du sie beim "can0 up" auf high ziehst. Dann reagiert dein CAN-Controller nämlich nicht mehr auf SPI, weil der ja nicht weiß, dass der ARM mit ihm sprechen will.
Danke für die Anregung, die CS Leitung ist Active Low und wird vom Treiber auch so gehandhabt. Interessant finde ich, dass nach can0 up das von außen eingehende CAN-Signal irgendwie kaputt geht, jedenfalls nicht mehr messbar ist... nach ifconfig can0 down ist es wieder sichtbar... Finde ich ziemlich schräg...
Prüf mal, ob du nicht wo nen Kurzschluss hast, der deine CAN-leitungen runter/hochzieht. Weil alles, was du über den Treiber machst, beeinflusst ja nur den Controller (den 2515) aber nicht den Transceiver (2551), der kriegt ja nur RX/TX vom Controller und das wars, d.h. er läuft eigentlich immer. Übrigens ganz nebenbei: was hast da für nen quarz drauf für den 2515?
10 Mhz Quarz. Mehr Details zu dem Bauteil hab ich leider nicht. Eigentlich hab ich alles nach Kurzschluss abgesucht, dachte ich. Ich sehe das exakt so, wie du das oben beschrieben hast und bin deshalb sehr verwundert, dass sich auch das Signal am 2551 ändert, obwohl nach der Initialisierung beim Starten von can0 überhaupt keine Kommunination stattfindet. Wo könnte da denn ein Kurzschluss sein? (Obwohl ich bisher partout keinen finden kann...) Ich bin völlig ratlos...
Der MCP2551 ist nicht mit 3.3V lauffähig, siehe Datenblatt. Für 3.3V muss ein anderer Transceiver drann...
Nya, viele details bei Quarzen gibts ja nicht, Frequenz, Package und Benötigte Kapazität, wobei nur das erste wirklich relevant ist. Teilst du dem 2515 irgendwie gesagt, welche Frequenz er nutzen soll? Wie schnell läuft dein ARM? (Bin gerade dabei, was mit CAN zu bauen, drum hats sich angeboten, dich da ein wenig auszufragen :P ) Also, der 2551 ist ja ein "dummer" wandler von TX/RX auf Differentiell, d.h. der kriegt keine Kommandos vom 2515, die ihm sagen, was er tun soll. der 2515 hat unmengen an outputs, dafür als input (vom ARM) nur das SPI mit !CS, !RS und noch die !TXRTS. Letztere sind aber eher irrelevant. D.h. wenn du can0 up setzst, zieht dein ARM theoretisch !CS auf Low (is active-low) und !RS ist permanent auf high durch Pullup (Auch active-low). Nichts von dem Dürfte den 2551 beeinflussen. Wenn dein can0 auf up ist, wird das CAN-Signal auf der CAN-Leitung nicht mehr messbar. D.h. deine Leitungen werden entweder gegen Low gezogen, was auch Sinn ergeben würde, denn CANH zieht eine 1 hoch (positive Spannung) und CANL zieht sie runter (negative Spannung), falls ich das hier korrekt deute: http://www.pc-oscilloscopes.com/images/canbus_waveform_1.jpg Alternativ kann es auch sein, dass dein Sender aus welchem Grund auch immer aufhört zu senden, sobald du can0 auf up stellst.
Wurststulle schrieb: > Hier der geänderte Schaltplan, das Problem besteht immer noch... Andere > Ideen wie es zu diesem Problem kommen kann? Ich würd den Reset nicht so anschließen sondern vom Linux aus steuern. So wie im Schaltplan angezeigt sieht der MCP nie einen Reset, weil der dann schon high ist wenn die Versorgung im IC auch erste Schritte erlaubt.... Siehe auch den ausdrücklichen Hinweis dazu im Datenblatt vom MCP2515 Und ich traue inzwischen keinem Chiphersteller mehr wenn er schreibt, daß ein SPI-Reset ident mit einem Hardwarereset ist. BTDT und nie wieder... Die - bis auf den Reset - identische Schaltung zw. Linux und MCP2515 tut seit 6 Jahren (mit 4MHz Quarz) hier in Stückzahlen ihren vollkommen problemlosen Dienst. Grüße MiWi
Die Frequenz des Quartz' ist eingestellt. "ifconfig can0 up" ist die Operation, mit der das entsprechende Netzwerk auf dem Board aktiviert wird und wo die Initialisierung des MCP2515 vom Linux-Kernel angestoßen wird. Das hat an sich erstmal nichts mit dem Pegel der CAN-Leitung zu tun. War vll blöd formuliert.
Wurststulle schrieb: > Was kann da schief laufen? Fehler in der Schaltung? Treiberproblem (der > ist im Linuxkernel integriert...). Ich bin ziemlich ratlos und hoffe ihr > habt eine Idee, was da schief laufen könnte? Ah ja, einen hab ich noch: IIRC muß das Linux bzw der Treiber auch den richtigen Interrupt wissen, weil sonst kommt einer, Linux sieht den nicht und das war es dann. Daher die Frage: am Linux den richtigen Interrupt angeschlossen? Der Treiber macht meiner Erinnerung nach keine vollständige Suche nach dem richtigen Interrupt und /CS (aber das war 2006...) und... schweigen im Wald, nix geht mehr Grüße MiWi
Das mit dem Interrupt hab ich überprüft, hab dem Treiber die richtige Interruptleitung mitgegeben. Kommt allerdings nie einer vom 2515 an. Weder bei cat /proc/interrupts (immer 0) noch mit dem Oszilloskop sichtbar. Wie machst du das mit dem Reset? Vor dem Starten des Treibers Pin für Reset einmal kurz auf low und dann wieder high? Oder hast du was am Treiber rumgebaut?
Hallo Wurststulle, kannst Du die Ausgabe von: dmesg | egrep -i "can|mcp" ; ifconfig -a ; ip -s -d link show can0 ; cat /proc/interrupts posten und die Boarddefinititionsdatei anhängen ? Hast Du CAN Debug aktiviert ? Gruß Mountain
Wurststulle schrieb: > Wie machst du das mit dem Reset? Vor dem Starten des Treibers Pin für > Reset einmal kurz auf low und dann wieder high? Oder hast du was am > Treiber rumgebaut? Keine Ahnung über die Details, das hat alles mein Programmierer gemacht. Aber im Grunde sieht es so aus: Wenn das Linux bootet hat wird irgendwann der gesamte IO-Bereich (LCD-Controller, CAN, LAN.. und was weiß ich noch alles) resetiert und dann erneut initialisiert. Die Hardware für`s Linux ist so gekapselt, daß da nur ein eine rabiate Störung (Stromausfall) was außer Tritt bringen kann (also keine direkte Leitung nach draußen). Die Schnittstellen (CAN, LCD, Tastatur, LAN etc) können aber aus welchen Gründen auch immer einmal zickig sein. Dürfen sie auch, denn dann bekommen sie einen Tritt mit dem IO-Reset und alles ist wieder gut. Oder auch nicht, aber selbst dann ist das Linux Herr der Lage und kann kontrolliert damit umgehen. iaW: das Linux läuft problemlos mehrere Jahre durch, je nach Umgebung wird die Peripherie in dieser Zeit jedoch öfteres resetiert ohne das es dadurch zu einem Systemausfall kommt. Sehr praktisch das alles. Grüße MiWi
CAN-Debug ist in den Kernel eincompiliert. Genaue Ausgaben kann ich erst nächste Woche liefern, aus der Erinnerung: dmesg: CAN started. mcp251x probed. ifconfig zeigt nach "ifconfig can0 up" can0 an Darauf kommt bei dmesg noch eine Ausgabe CANSTAT und zwei Hex-Werte. cat /proc/interrupts zeigt ... mcp2515: 0 ... Boarddatei ist im Anhang. Danke.
Hallo Wurststulle, eine weitere Sache ist mir noch in Deinem Schaltplan aufgefallen: Der Interrupt ist "activ low" - ich vermisse den PullUp Widerstan am INT. Für die Initialisierung des MCP2515 (Softreset und Parameterisierung) wird der Interrupt nicht benötigt. Das mcp251x Modul initialisiert den CAN Controller so, das der INT bei ankommenden Paketen bzw. Fehlersituationen ausgelöst wird Ich würde folgende Tests vorschlagen um den Fehler einzukreisen: - den MCP2515 in Loopbackmodus versetzen: # ifconfig can0 down # ip link set can0 type can up bitrate 125000 loopback on # candump -e any,0:0,#FFFFFFFF # # neue SSH Session # cansend can0 123#deadbeef Schauen ob etwas passiert - ggf. kann das Board dabei abstürzen, sofern die Interrupt-Behandlung nicht korrekt ist. Als zweiten Test würde ich analog zu http://lnxpps.de/rpie/ den GPIO Test durchführen. Gruß Mountain
Mountain schrieb: > Hallo Wurststulle, > > eine weitere Sache ist mir noch in Deinem Schaltplan aufgefallen: > Der Interrupt ist "activ low" - ich vermisse den PullUp Widerstan am > INT. Das ist ein Push/Pull Ausgang vom MCP2515 (Siehe Datenblatt bei High level Output Voltage), braucht daher keinen Pullup. Grüße MiWi
MiWi schrieb: > Das ist ein Push/Pull Ausgang vom MCP2515 (Siehe Datenblatt bei High > level Output Voltage), braucht daher keinen Pullup. > > Grüße > > MiWi Ich bin offensichtlich zu ungeübt im Datenblatt Lesen: Min Max Voh /INT VDD-0.7V - Ioh -1.0mA, Vdd 4.5V Wie erkenne ich daraus, das kein PullUp benötigt wird ? Gruß Mountain
Mountain schrieb: > MiWi schrieb: >> Das ist ein Push/Pull Ausgang vom MCP2515 (Siehe Datenblatt bei High >> level Output Voltage), braucht daher keinen Pullup. >> >> Grüße >> >> MiWi > > Ich bin offensichtlich zu ungeübt im Datenblatt Lesen: > > Min Max > Voh /INT VDD-0.7V - Ioh -1.0mA, Vdd 4.5V > > Wie erkenne ich daraus, das kein PullUp benötigt wird ? > > Gruß Mountain der Pin kann 1mA bei 3,8V (Vdd= 4,5V-0,7V) gemessener Spannung (V_OH)am Pin treiben. Und das geht nicht mit bei einem Opencollector. Der könnte nur Strom aufnehmen. Abgesehen davon steht nirgends im Datenblatt, daß es ein OpenCollector oÄ ist. Und in den ANs um diesen Chip herum wirst Du auch nie einen Pullup auf der /INT finden. Grüße Miwi
MiWi schrieb: >> Ich bin offensichtlich zu ungeübt im Datenblatt Lesen: >> >> Min Max >> Voh /INT VDD-0.7V - Ioh -1.0mA, Vdd 4.5V >> >> Wie erkenne ich daraus, das kein PullUp benötigt wird ? >> >> Gruß Mountain > > der Pin kann 1mA bei 3,8V (Vdd= 4,5V-0,7V) gemessener Spannung (V_OH)am > Pin treiben. Und das geht nicht mit bei einem Opencollector. Der könnte > nur Strom aufnehmen. > > Abgesehen davon steht nirgends im Datenblatt, daß es ein OpenCollector > oÄ ist. Und in den ANs um diesen Chip herum wirst Du auch nie einen > Pullup auf der /INT finden. > > Grüße > > Miwi Ah - OK. Vielen Dank. Gruß Mountain
Wurststulle schrieb: > Hier der geänderte Schaltplan, das Problem besteht immer noch... Andere > Ideen wie es zu diesem Problem kommen kann? Hallo Wurststulle, also beim CAN-Bus ist das mit RX und TX etwas anders. Der CAN-Kontoler ausgang TX muss mit dem Anschluß TX vom MCP2551 und RX vom 2515 mit RX vom 2551 verbunden sein. Das Dominante BIt (low-Level) wird über RX zurückgelesen. Wenn Du es vertauschst, dann funktioniert das RÜcklesen der gesendeten Bits nicht und die Arbitrierung vom Physikalischen Bus kann protokollgemäß nicht durch geführt werden. Es gibt dann einen Bit-Fehler. Nach 128 Sendeversuchen würde der Kontroler in den BUS-Passiv-Modus gehen. Falls Dein Treiber die Fehlerquellen auslesen ermöglicht, dann schaue da mal nach. wen da Bitfehler steht, dann tausche die Leitungen.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.