CAN-Kommunikation funktioniert nicht

CANH (Kanal 2) und CANL (Kanal 0) erhalten Informationen

Wenn Kanal 2 wirklich CANH ist, mit der gleichen Zeitbasis wie CANL auf Kanal 0, dann ist das offensichtlich Ihr Problem. Es sieht überhaupt nicht gesund aus, es sollte wie ein differentieller Spiegel von CANL aussehen.

• Ich würde vermuten, dass etwas wie CANH gegen ein anderes Signal kurzgeschlossen wird oder dass sich etwas in der CAN-Transceiver-Schaltung falsch verhält (schlechtes Löten?).

• Stellen Sie außerdem sicher, dass keine Pull-Widerstände zwischen der MCU und dem Transceiver oder innerhalb der MCU in den Portregistern vorhanden sind. Wenn dies das Problem wäre, würde dies logischerweise auch dazu führen, dass CANL fehlschlägt.

• Fügen Sie immer 2x 120 Ohm Abschlusswiderstände hinzu, einen an jedem Ende des Busses, auch wenn Sie mit langsamen Baudraten und kurzen Entfernungen arbeiten. Ein gewisser Impedanzunterschied von ungefähr 60 Ohm zwischen CANH und CANL ist oft erforderlich, damit die CAN-Schaltung glücklich bleibt.

• Schließen Sie natürlich eine Signalerde zwischen jedem Knoten an, wie es vom CAN-Standard gefordert und vorgeschrieben wird. Andernfalls sind Sie dem Massepotential Ihrer Knoten ausgeliefert, und wenn auf der Versorgungsmasse hohe Masseströme vorhanden sind, kann dies die CAN-Kommunikation beeinträchtigen, wenn keine dedizierte Signalmasse verwendet wird.

  Unter Nicht-Ingenieuren kursiert ein Mythos, dass man für differentielle Signale keine Signalmasse braucht, aber das ist Unsinn, es sei denn, der CAN-Bus ist mit Optokopplern oder ähnlichem galvanisch getrennt. Differenzialsignale sind lediglich viel robuster als andere Signale, sodass sie glücklicherweise auch dann funktionieren können, wenn das Systemdesign schlecht ist und keine Signalmasse enthält. CAN-Transceiver können einer Potentialdifferenz von bis zu 40 V standhalten, bevor die Kommunikation beeinträchtigt wird.

Das rote X auf Ihrem Oszilloskop ist kein Fehler, sondern Bitstuffing. Ihr Bereich fügt sie dort hinzu, um anzuzeigen, dass sie nicht Teil der eigentlichen Daten sind. Es ist wie erwartet, Sie sollten immer ein Füllbit nach 5 aufeinanderfolgenden High/Low-Bits in einem CAN-Frame haben.

Ein offensichtliches Problem ist, dass Sie keine Abschlusswiderstände auf dem CAN-Bus haben. Denken Sie daran, dass sie nicht nur zum Abschluss der Übertragungsleitung dienen, sondern auch die Zusammenziehwiderstände sind, damit der Bus im rezessiven Zustand ist, wenn er nicht explizit angesteuert wird.

Wenn sich dies auf einer einzelnen Platine befindet, können Sie davonkommen, indem Sie etwa 60 Ω zwischen CANL und CANH legen. Wenn der CAN-Bus ein echtes Kabel ist, legen Sie an jedem Ende 120 Ω zwischen CANL und CANH. In diesem Fall muss das Kabel auch geerdet sein, damit beide Geräte den gleichen Massebezug verwenden.

Ich habe hier eine enorme Menge an Vorschlägen, Argumenten und Gegenargumenten durchgesehen, und ich denke, all dies hat Ihnen einen schlechten Dienst erwiesen. In CAN steckt keine Magie, und hier ist der Beweis:

Dieses schreckliche Durcheinander auf meinem Schreibtisch ist ein schnelles und schmutziges Testfeld für einige Software, an der ich gerade arbeite. Es verfügt über zwei Dual-Motor-Controller mit CAN-Schnittstellen und AVR, die über MCP2515-Controller + TJA1050-Transceiver (genau das gleiche wie Sie!) mit CAN verbunden sind.

Die Motorsteuerungen sind mit 3 Drähten verbunden (einschließlich Masse), aber der AVR hat nur 2. Ich habe nicht einmal einen geraden Bus - es ist alles Stern am unbenutzten (im Moment gab es dort vorher einen anderen Controller) DB15-Stecker, den ich eingekreist habe auf dem Foto. Sie können einen einzelnen 100-Ohm-Widerstand sehen, der dort sitzt und alle CANL und CANH miteinander verbindet. Und bei 500kb/s funktioniert alles einwandfrei.

Ich behaupte nicht, dass dies der richtige Weg ist, Dinge zu tun. Ich sage nur, dass bei dieser Entfernung und Geschwindigkeit, ohne Störungen und mit stabiler Leistung all diese feinen Details und Know-hows einfach keine Rolle spielen.

Also, hier ist, was ich vorschlage.

1. Deine Schaltpläne sind in Ordnung. Stellen Sie sicher, dass alle RX, TX, CANL, CANH entsprechend angeschlossen sind (auch wenn Sie wissen, dass sie in Ordnung sind, schadet es nie, sie zu überprüfen).

2. Lassen Sie diese 120-Ohm-Widerstände auf den Modulen.

3. Sie können die Erdung von zwei TJA1050 miteinander verbinden, wenn Sie möchten, aber wenn Ihr Setup so ähnlich wie meines ist, spielt es absolut keine Rolle, da alles von derselben Versorgung gespeist wird und die Entfernung vernachlässigbar ist.

4. Schließen Sie Ihren Logikanalysator an, um TX (an Masse) auf der Sendeseite und RX (an Masse) auf der Empfangsseite zu messen. Ich glaube, dies wurde bereits mindestens dreimal vorgeschlagen, aber ich habe nie die Ergebnisse gesehen.

5. Führen Sie Ihre Programme aus. Sie sollten auf RX genau das gleiche Signal sehen wie auf TX. Wenn nicht, liegt das Problem irgendwo in der CAN-Verbindung. Aber wenn Sie dies tun, liegt das Problem in der Software, höchstwahrscheinlich in der Filter- oder Maskenkonfiguration.

AKTUALISIEREN

Der springende Punkt beim direkten Anschließen von Controllern bestand darin, den physischen Aspekt (so weit wie möglich) zu eliminieren. Wenn die Drähte kurz sind, die Dioden schnell sind und der Pull-up korrekt ist, sollte es keinen Unterschied an den RX-Pins geben. Stellen Sie sicher, dass Sie Pull-up mit Ihrem tatsächlichen Vcc verbinden (dieses Dokument wurde für ein 5-V-System geschrieben).

Ich schlage vor, Ihre Verbindungen einmal zu überprüfen und die Verdrahtungsfrage beiseite zu legen. Konzentrieren wir uns auf die Softwareseite. So würde ich es diagnostizieren.

1. Minimieren Sie Ihren Code. Das einzige, was Sie auf der TX-Seite haben sollten, ist gerade genug, um einmal pro Sekunde einen Basisdatenrahmen in einer Schleife zu senden. Ich schlage vor, eine einfache zyklische Ein-Byte-Sequenznummer zu übertragen. Das einzige, was Ihre RX-Seite haben sollte, ist gerade genug, um dieses Byte zu lesen und es vielleicht im Debug auszudrucken. Es sollte nichts zurückgeschickt werden, um eine Kontamination des Tests zu vermeiden.

2. Debuggen Sie zuerst TX. Sie haben erwähnt, dass Sie an einem Punkt nur eine Nachricht herausbekommen haben. Das Ziel Nr. 1 ist also sicherzustellen, dass TX diese Nachrichten jede Sekunde sendet. Und Sie sollten sie mit Ihrem Logikanalysator auf diesem Eindrahtbus sehen.

Häufige Probleme hier: falsche Verwendung von Sendepuffern, falsche Behandlung von EOT, fehlerhafter Datenrahmen (ID, Steuerbits usw.). Überprüfen Sie auch, wie Ihre Bibliothek/Ihr Controller mit dem ACK-Bit umgeht. Technisch nicht erforderlich, aber einige Implementierungen könnten versuchen, dieselbe Nachricht immer wieder neu zu übertragen, bis ACK empfangen wird, wodurch Tx-Puffer daran gehindert werden, neue Daten zu erhalten.

3. Bewegen Sie sich mit dieser Arbeit zur RX-Seite und prüfen Sie, ob diese Sequenznummer ordnungsgemäß empfangen wird.

Häufige Probleme hier: unterschiedliche Datenrate, falsche Verwendung von RX-Puffer, falsche Behandlung von Interrupts, falscher Filter oder Filtermaske. Es könnte hilfreich sein, Ihre Filter so zu konfigurieren, dass sie zu Beginn jede Nachricht akzeptieren .

4. Nur wenn sowohl TX als auch RX ordnungsgemäß funktionieren, können Sie den Sende- und Empfangscode kopieren und mit der Arbeit an der bidirektionalen Anfrage-Antwort-Kommunikation beginnen.

Obwohl ich es noch nicht versucht habe (ich brauchte CAN schließlich nicht), besteht die Lösung darin, innerhalb von STM32CubeMX die HAL F1-Bibliothek auf 1.7 (oder höher) zu aktualisieren, wo die CAN-Implementierung behoben/geändert wurde.