CAN-Bus am STM32: Kommunikation für Automotive und Industrie

Der CAN-Bus am STM32 ist eine der wichtigsten Schnittstellen, wenn es um robuste Kommunikation in Automotive- und Industrieanwendungen geht. CAN (Controller Area Network) wurde dafür entwickelt, viele Steuergeräte zuverlässig über zwei Leitungen zu vernetzen – auch in Umgebungen mit Störungen, langen Kabelwegen und harten EMV-Anforderungen. STM32-Mikrocontroller eignen sich dafür besonders gut, weil viele Varianten integrierte CAN-Controller (klassisch: bxCAN, modern: FDCAN) bieten und sich die Peripherie über STM32CubeMX, HAL oder register-nah präzise konfigurieren lässt. In der Praxis ermöglicht CAN am STM32 eine deterministische Datenübertragung für Sensoren, Aktoren, Antriebe, Diagnosesysteme oder Gateways. Gleichzeitig gibt es typische Stolpersteine: Bit-Timing, Terminierung, Filter, Interrupt-Handling, Bus-Off-Recovery und die saubere Auswahl des Transceivers. Dieser Artikel erklärt die Grundlagen verständlich, zeigt die relevanten STM32-spezifischen Konzepte und führt durch die wichtigsten Schritte – von der Hardware über die Konfiguration bis zur Fehleranalyse – damit Ihr System im Feld stabil und nachvollziehbar funktioniert.

Was ist CAN-Bus und warum ist er so verbreitet?

CAN ist ein serielles Feldbussystem, das Nachrichten (Frames) paketorientiert überträgt. Es ist besonders, weil es nicht nach dem Prinzip „Adresse = Empfänger“ arbeitet, sondern nach dem Prinzip „Nachricht = Identifier“. Alle Teilnehmer lauschen auf dem Bus; ein Knoten entscheidet anhand des Identifier (ID), ob die Nachricht relevant ist. Das ist ideal für verteilte Systeme: Ein Sensor sendet beispielsweise zyklisch Messwerte, mehrere Steuergeräte können diese parallel nutzen, ohne dass der Sender wissen muss, wer die Daten empfängt.

• Robust: Hohe Störfestigkeit durch differentielles Signal (CAN_H/CAN_L) und Fehlermechanismen.
• Priorisiert: Arbitration sorgt dafür, dass wichtige Nachrichten bevorzugt durchkommen.
• Echtzeitnah: Deterministisches Verhalten bei sinnvoller Buslast und Nachrichtenplanung.
• Ökosystem: Breite Unterstützung in Automotive (z. B. Diagnose) und Industrie (z. B. CANopen).

Eine gute, allgemeine Einführung bietet der Artikel zum Controller Area Network (CAN). Für die technische Normung lohnt zusätzlich ein Blick auf die Grundlagen von ISO 11898, die die CAN-Physik und Protokollaspekte beschreibt.

Physikalische Schicht: Transceiver, Terminierung und Verkabelung

Der STM32 stellt in der Regel nur den CAN-Controller bereit. Für das eigentliche Bussignal benötigen Sie einen CAN-Transceiver (z. B. aus der TJA-, SN65HVD-, MCP- oder ähnlichen Familien). Der Transceiver wandelt die logischen TX/RX-Signale des Controllers in das differentielle Bussignal um. Ohne Transceiver funktioniert CAN in der Praxis nicht, weil Pegel, Treiberstärke, Schutzfunktionen und EMV-Verhalten fehlen.

• Terminierung: An beiden Busenden je ein 120-Ohm-Abschlusswiderstand (typisch). Ohne korrekte Terminierung entstehen Reflexionen und Kommunikationsfehler.
• Topologie: Lineare Busstruktur mit kurzen Stichleitungen ist Standard. Lange Abzweige erhöhen Fehlerrisiko.
• Kabellänge vs. Baudrate: Je höher die Baudrate, desto kürzer sollte der Bus sein. In der Praxis sind 500 kbit/s oder 1 Mbit/s häufig, abhängig von Leitung und Umgebung.
• Massebezug: Differenziell bedeutet nicht „masselos“. Eine gemeinsame Bezugspotenzialführung (und Schutzkonzept) ist wichtig.

Common-Mode, EMV und Schutzbeschaltung

In Industrie- und Automotive-Umgebungen sind Überspannungen, ESD und Störungen üblich. Nutzen Sie Transceiver mit passenden Schutzmerkmalen (oder ergänzen Sie TVS-Dioden). Achten Sie auf kurze, symmetrische Leiterführung von CAN_H/CAN_L, passende Impedanz und sinnvolle Platzierung der Terminierung. Für Details rund um STM32 und CAN-Peripherie ist die Dokumentationsübersicht von ST ein guter Startpunkt, etwa über die STM32CubeMX-Dokumentation und die jeweiligen Reference Manuals Ihrer MCU-Serie.

CAN-Frames: Identifier, Datenlänge und Arbitration

Ein klassischer CAN-Frame (CAN 2.0) transportiert bis zu 8 Datenbytes. Moderne Systeme nutzen zunehmend CAN FD (Flexible Data-Rate), das deutlich größere Nutzdaten (bis 64 Byte) erlaubt und bei geeigneter Konfiguration höhere Datenraten im Datenfeld unterstützt. STM32-Familien mit FDCAN-Peripherie sind dafür ausgelegt.

• Standard ID (11 Bit): Kompakter Identifier, häufig in Fahrzeugnetzwerken.
• Extended ID (29 Bit): Größerer Adressraum, oft bei komplexen Netzwerken oder J1939.
• DLC: Data Length Code, kodiert die Nutzdatenlänge.
• CRC und ACK: Mechanismen für Datenintegrität und Quittierung.

CAN nutzt eine sogenannte non-destructive arbitration: Wenn mehrere Knoten gleichzeitig senden, gewinnt die Nachricht mit der höheren Priorität (bei CAN: die kleinere ID). Die unterlegenen Knoten brechen ab und versuchen später erneut – ohne dass die gewinnende Nachricht beschädigt wird. Daraus folgt: Die ID ist nicht nur „Kennung“, sondern auch ein Prioritätsmechanismus. In Systemdesigns ist es daher wichtig, IDs bewusst zu planen, damit zeitkritische Nachrichten Vorrang haben.

Bit-Timing verstehen: Baudrate und Sample Point sauber einstellen

Ein stabiler CAN-Bus steht und fällt mit dem Bit-Timing. Der CAN-Controller erzeugt aus einem Peripherietakt die gewünschte Baudrate, indem er ein Bit in Zeitquanten (Time Quanta, TQ) unterteilt. Typisch sind ein Synchronisationssegment und zwei Zeitsegmente (TSEG1, TSEG2). Der Sample Point (Abtastpunkt) liegt meist im Bereich 70–87,5% des Bits, abhängig von Netzwerklänge und Transceiver-Eigenschaften.

Vereinfacht lässt sich die Baudrate so beschreiben:

$f_{\mathrm{CAN}}=\frac{f_{\mathrm{clk}}}{\mathrm{BRP}\cdot \mathrm{TQ}}$

Wenn ein Bit aus insgesamt N Zeitquanten besteht, gilt:

$N=1+\mathrm{TSEG1}+\mathrm{TSEG2}$

Damit ergibt sich:

$f_{\mathrm{CAN}}=\frac{f_{\mathrm{clk}}}{\mathrm{BRP}\cdot 1+\mathrm{TSEG1}+\mathrm{TSEG2}}$

Praktischer Hinweis zum Bit-Timing

In der Praxis wählen Sie zuerst die Baudrate (z. B. 500 kbit/s), dann eine sinnvolle Anzahl Zeitquanten pro Bit (häufig 8–20), und konfigurieren BRP, TSEG1, TSEG2 sowie SJW (Synchronisationssprungweite). Viele Hersteller bieten Rechner und Tabellen; bei STM32 unterstützt CubeMX die Auswahl, dennoch sollten Sie die resultierenden Parameter prüfen – insbesondere bei abweichenden Taktquellen oder wenn mehrere Bussegmente mit unterschiedlichen Leitungslängen existieren.

CAN am STM32: bxCAN vs. FDCAN

Welche CAN-Peripherie Sie haben, hängt von der STM32-Serie ab. Ältere und viele Mainstream-Serien nutzen bxCAN (klassischer CAN 2.0). Neuere Serien – insbesondere mit Fokus auf moderne Kommunikationsanforderungen – bieten FDCAN, das CAN FD unterstützt und oft mehr Flexibilität bei Filtern, FIFO-Handling und Timing bietet.

• bxCAN: CAN 2.0A/B, typischerweise 3 Tx-Mailboxes, Rx-FIFOs, Filterbank-Konzept.
• FDCAN: CAN FD (optional auch Classic CAN), größere Nutzdaten, getrenntes Nominal/Data Bit Timing, erweiterte Buffer-Strukturen.
• Transceiver bleibt nötig: Unabhängig von bxCAN/FDCAN benötigen Sie einen externen CAN-Transceiver.

Wichtig für die Auswahl: Wenn Sie zwingend CAN FD oder größere Nutzdaten benötigen, wählen Sie eine STM32-Serie mit FDCAN. Für viele klassische Fahrzeug- oder Industrienetzwerke reicht bxCAN jedoch weiterhin aus, solange die Bandbreite und Nutzdatenanforderungen passen.

Konfiguration mit STM32CubeMX: Schritt für Schritt zur laufenden Kommunikation

Der schnellste Weg zum funktionierenden CAN-Bus am STM32 führt meist über CubeMX. Der Ablauf ist konzeptionell ähnlich, egal ob bxCAN oder FDCAN – die Details unterscheiden sich aber bei Filtern und Buffern.

• Peripherie aktivieren: CAN (bxCAN) oder FDCAN einschalten und Pins als Alternate Function konfigurieren.
• Clock prüfen: Sicherstellen, dass der CAN-Kern korrekt getaktet wird (APB-Takt, Kernel Clock, ggf. PLL).
• Bit-Timing setzen: Baudrate, Sample Point und SJW auswählen. CubeMX zeigt oft die resultierenden Parameter.
• Filter definieren: Nur relevante IDs annehmen (entlastet CPU und reduziert Softwareaufwand).
• Interrupts/FIFOs: Rx-Interrupts aktivieren, FIFO/Buffer-Strategie festlegen.
• Start und Test: Controller starten, erste Testframes senden/empfangen, Buslast beobachten.

Filter richtig nutzen: Performance und Sicherheit

CAN-Filter sind mehr als „Komfort“. In stark belegten Netzen kann die CPU mit unnötigen Nachrichten überlastet werden, wenn Sie alles durchlassen. Filtern Sie daher gezielt nach Standard/Extended IDs und nutzen Sie Masken oder Listenfilter. In sicherheitskritischen Anwendungen hilft gutes Filtering außerdem dabei, nur erwartete Nachrichten zu akzeptieren und die Angriffsfläche zu reduzieren (ohne damit allein „Security“ zu ersetzen).

Sendelogik: Mailboxes, Queues und Timing im Griff behalten

Beim Senden ist wichtig, dass Ihr System nicht „blind“ Frames in schneller Folge absetzt, sondern eine Strategie verfolgt: Was ist zyklisch, was ereignisgesteuert, was ist diagnostisch? Gerade in Automotive-Netzen sind zyklische Nachrichten üblich, während Diagnose und Flash-Programmierung sporadisch stattfinden. Auf STM32-Seite stehen dafür je nach Peripherie Mailboxes (bxCAN) oder dedizierte Tx-Queues/Buffers (FDCAN) zur Verfügung.

• Zyklische Telegramme: Feste Periode, feste ID, definierte Payload-Struktur.
• Ereignisframes: Nur bei Zustandsänderung (z. B. Fehler, Grenzwert überschritten).
• Diagnose: Request/Response-Pattern, häufig mit Timeouts und Session-Logik.

Für saubere Echtzeitfähigkeit sollten Sie Sendevorgänge nicht unkontrolliert in hochpriorisierten Interrupts erledigen. Häufig ist ein Ansatz sinnvoll, bei dem Applikationsdaten in eine Warteschlange geschrieben werden und ein Kommunikations-Task oder ein moderater Interrupt-Kontext die Frames abarbeitet.

Empfangslogik: Interrupts, FIFO-Handling und Datenkonsistenz

Beim Empfang sind zwei Aspekte entscheidend: Sie müssen die Nachrichten zuverlässig abholen, und Sie müssen sie in der Anwendung konsistent verarbeiten. In vielen Projekten ist eine Interrupt-basierte Lösung der Standard: Der CAN-Controller signalisiert „Nachricht angekommen“, die ISR (oder ein HAL-Callback) holt sie aus dem FIFO und legt sie in einen Software-Puffer, den die Applikation später auswertet.

• Interrupt-basiert: Gute Reaktionszeit, geringere Gefahr von FIFO-Überläufen, wenn sauber implementiert.
• Polling: Einfacher für erste Tests, aber riskant bei hoher Buslast oder wenn andere Tasks blockieren.
• Ringpuffer: Bewährt, um Burst-Empfang zu glätten und die Anwendung zu entkoppeln.

Payload-Strukturen und Endianness

CAN überträgt Bytes. Die Interpretation (z. B. 16-bit, 32-bit, signed/unsigned, Skalierung) ist Teil Ihrer Applikations- oder Protokolldefinition. Legen Sie Payload-Layouts klar fest, dokumentieren Sie Skalierungen (z. B. Temperatur = Wert/10) und entscheiden Sie sich konsistent für Endianness. In heterogenen Systemen (verschiedene MCU-Architekturen) verhindert das spätere Fehlersuche.

Fehlerbehandlung: Error Counters, Bus-Off und Recovery

CAN hat eingebaute Fehlererkennung und automatische Wiederholungen. Das schützt vor vielen transienten Problemen, kann aber auch dazu führen, dass ein System scheinbar „einfach aufhört“, wenn die Fehler zu häufig auftreten. Der Controller führt Sende- und Empfangsfehlerzähler (TEC/REC) und wechselt bei Problemen in Zustände wie Error Passive oder Bus-Off. Bus-Off bedeutet: Der Knoten trennt sich logisch vom Bus, um das Netzwerk nicht zu stören.

• Error Active: Normalbetrieb, Fehler werden korrigiert, Retransmissions möglich.
• Error Passive: Knoten ist „vorsichtiger“, um das Netz weniger zu belasten.
• Bus-Off: Knoten sendet nicht mehr; Recovery muss kontrolliert erfolgen.

Für robuste Systeme ist eine definierte Recovery-Strategie wichtig: Ursachenanalyse (z. B. fehlende Terminierung, falsches Bit-Timing, defekter Transceiver), Logging der Zustände und ein kontrolliertes Wiederanlaufen, statt „Endlosschleife resetten“. In Automotive-Anwendungen wird Recovery oft normativ geregelt oder durch Systemanforderungen vorgegeben.

Automotive-Use-Cases: Diagnose, Gateways und Protokolle

Im Automotive-Bereich ist CAN zentral für Steuergerätekommunikation, Diagnose und Gateway-Funktionen. Typische Anwendungen sind:

• OBD/Diagnose: Diagnosekommunikation (z. B. UDS) nutzt CAN als Transportmedium in vielen Fahrzeugen.
• Gateway: Übersetzen zwischen Netzen (z. B. mehrere CAN-Segmente) oder zwischen CAN und Ethernet/LIN.
• J1939: Häufig in Nutzfahrzeugen, basiert auf Extended IDs und definierten PGNs.

Wenn Sie sich in Diagnoseprotokolle einarbeiten möchten, ist ein Einstieg über die Beschreibung von On-Board-Diagnose (OBD) hilfreich. Für industrielle Protokolle auf CAN-Basis lohnt ein Blick auf CANopen, das in Automatisierung und Maschinenbau sehr verbreitet ist.

Industrie-Use-Cases: CANopen, Sensorik und verteilte Steuerungen

In der Industrie ist CAN beliebt, weil es über moderate Distanzen stabil läuft, kostengünstig ist und sich gut für dezentrale Architekturen eignet. Häufige Szenarien:

• Dezentrale I/O: Sensor-/Aktor-Module am Bus, zentrale Steuerung liest/verteilt Werte.
• Antriebstechnik: Motorcontroller, Frequenzumrichter oder Servoregler mit CANopen-Profilen.
• Mobile Systeme: Landwirtschaft, Robotik, Transportfahrzeuge – überall dort, wo EMV und Mechanik fordern.

Für STM32-Projekte empfiehlt es sich, die CAN-Softwarearchitektur früh zu strukturieren: Treiber (HAL/LL), Protokollschicht (z. B. CANopen-Stack), Applikationsdatenmodell und Diagnose/Logging. Dadurch bleibt die Anwendung wartbar, wenn das Netzwerk wächst oder mehrere Produktvarianten unterstützt werden müssen.

Test und Inbetriebnahme: Werkzeuge, Busmonitoring und typische Messpunkte

Ein CAN-System wird deutlich schneller stabil, wenn Sie von Anfang an mit geeigneten Tools testen. Ein USB-CAN-Adapter mit Busmonitor erlaubt das Mitschneiden von Frames, das Senden von Testtelegrammen und das Prüfen von IDs, Datenfeldern und Zeitverhalten. Zusätzlich ist ein Oszilloskop hilfreich, um Signalqualität, Reflexionen oder Störspitzen zu erkennen.

• Busmonitor: Frames live ansehen, filtern, loggen (IDs, DLC, Daten, Zeitstempel).
• Loopback/Silent Mode: Controller-intern testen, ohne das reale Busnetz zu beeinflussen (je nach Peripherie verfügbar).
• Signalprüfung: CAN_H/CAN_L differenziell betrachten, Terminierung kontrollieren (typisch ~60 Ohm zwischen H und L bei zwei 120-Ohm-Endwiderständen).

Typische Fehlerbilder und schnelle Ursachen

• Kein Empfang, aber Senden scheint zu laufen: Falsche Pins/AF, Filter blockieren alles, Silent Mode aktiv.
• Viele Error Frames/Bus-Off: Bit-Timing falsch, Terminierung fehlt, Leitungsprobleme, Transceiver inkompatibel oder defekt.
• Nur sporadische Aussetzer: EMV, Masseprobleme, zu lange Stichleitungen, schlechte Steckverbinder.
• Bus lahmt bei Last: Zu viele zyklische Nachrichten, ungünstige Prioritäten (ID-Plan), CPU überlastet durch fehlende Filterung.

Best Practices für stabile Systeme: Design, Dokumentation und Wartbarkeit

Ein zuverlässiger CAN-Bus am STM32 ist nicht nur eine Frage der Registerwerte, sondern des Gesamtdesigns. Bewährte Vorgehensweisen:

• ID-Planung: IDs nach Priorität und Funktion strukturieren, Kollisionen vermeiden, Erweiterbarkeit einplanen.
• Filter konsequent nutzen: Nur relevante Nachrichten an die Anwendung durchlassen.
• Timeouts und Watchdogs: Kommunikationsausfälle erkennen und definierte Zustände einnehmen.
• Logging: Error Counters, Bus-Off-Ereignisse und wichtige Zustandswechsel protokollieren.
• Versionierung der Botschaften: Payload-Layouts dokumentieren und Änderungen kompatibel gestalten.

Für die Umsetzung am STM32 ist es hilfreich, die offiziellen Ressourcen je nach MCU-Serie heranzuziehen (Reference Manual, Datasheet, HAL/LL-Dokumentation). Ein guter Einstiegspunkt ist das STM32CubeIDE-Umfeld, das Code-Generierung, Debugging und Peripheriekonfiguration zusammenführt. Wenn Sie konsequent Hardware (Transceiver, Terminierung, Layout) und Software (Bit-Timing, Filter, Fehlermanagement) gemeinsam betrachten, erhalten Sie ein CAN-System, das sowohl im Labor als auch im realen Feldbetrieb stabil bleibt.

IoT-PCB-Design, Mikrocontroller-Programmierung & Firmware-Entwicklung

PCB Design • Arduino • Embedded Systems • Firmware

Ich biete professionelle Entwicklung von IoT-Hardware, einschließlich PCB-Design, Arduino- und Mikrocontroller-Programmierung sowie Firmware-Entwicklung. Die Lösungen werden zuverlässig, effizient und anwendungsorientiert umgesetzt – von der Konzeptphase bis zum funktionsfähigen Prototyp.

Diese Dienstleistung richtet sich an Unternehmen, Start-ups, Entwickler und Produktteams, die maßgeschneiderte Embedded- und IoT-Lösungen benötigen. Finden Sie mich auf Fiverr.

Leistungsumfang:

• IoT-PCB-Design & Schaltplanerstellung

• Leiterplattenlayout (mehrlagig, produktionstauglich)

• Arduino- & Mikrocontroller-Programmierung (z. B. ESP32, STM32, ATmega)

• Firmware-Entwicklung für Embedded Systems

• Sensor- & Aktor-Integration

• Kommunikation: Wi-Fi, Bluetooth, MQTT, I²C, SPI, UART

• Optimierung für Leistung, Stabilität & Energieeffizienz

Lieferumfang:

• Schaltpläne & PCB-Layouts

• Gerber- & Produktionsdaten

• Quellcode & Firmware

• Dokumentation & Support zur Integration

Arbeitsweise:Strukturiert • Zuverlässig • Hardware-nah • Produktorientiert

CTA:
Planen Sie ein IoT- oder Embedded-System-Projekt?
Kontaktieren Sie mich gerne für eine technische Abstimmung oder ein unverbindliches Angebot. Finden Sie mich auf Fiverr.