CAN-Bus Analyzer I ( CAN-Bus Finder)

Projektstand:
Januar 2009 - Prototyp der Hardware wurde erfolgreich auf einer Lochrasterkarte aufgebaut. Mittels Testprogramm wurden alle Hardwarefunktionen erfolgreich getestet. Somit muss nur noch ein bisschen Software :-) geschrieben werden.

Allgemeines:
Der CAN-Bus (Controller Area Network) ist ein Datenbus, welcher in der heutigen Fahrzeugen nicht mehr wegzudenken ist. Entwickelt wurde er von Bosch in den 80er Jahren. Mit dem ISO-Standard ISO 11898 wurde das Protokoll für die Anwendung im PKW international standardisiert.

CAN ist das derzeit am häufigsten eingesetzte Kfz-Bussystem für Low-Speed und Highspeed Anwendungen.
Meistens kommen mehrere CAN-Busse mit unterschiedlichen Baudraten im PKW zum Einsatz:

• Motor-CAN (High-Speed-CAN: 500kBit/s) für Motorsteuerung, Getriebesteurung, Bremsen, usw.
• Komfort-CAN ( Low-Speed-CAN: 50kBit/s, 100kBits/s, 125kBits/s) für Klima, Tür, Lichtsteureung usw.
• Infotaiment-CAN (Low-Speed-CAN 50kBit/s, 100kBits/s, 125kBits/s) für Navigation, Radio, LFB usw.

Beim CAN-Bus erfolgt die Datenübertragung auf einer Zwei-Draht-Leitung (CAN-High und CAN-Low) Leitung, deren gemeinsamer Bezugspunkt die Masse Leitung ist. Üblicherweise sind diese 2 Leitungen auch miteinander verdrillt (Twisted Pair) wodurch eine besserer EMV erreicht wird. Ein weiteres Merkmal des CAN-Busses ist, dass keine Geräte (man spricht hier von CAN-Knoten) direkt addressiert werden, sondern eine CAN-Message aus einem Identifier (Message ID) und bis zu 8 Datenbytes besteht. z.B. (LEN gibt die Anzahl der Datenbytes an)
ID LEN Datenbytes Kommentar
351 8 00 00 00 00 00 00 00 00 Message in der die Geschwindigkeitinformation bei VW-Fahrzeugen enthalten ist

Dies sollte mal als kurze Einführung reichen. Weitere Informationen zum CAN-Bus sind unten bei den Links zu finden.

Kurzbechreibung:
Der CAN-Bus-Analyzer erkennt automatisch das Format des CAN-Bus Protokolls ( 11-Bit Identifier oder 29-Bit Identifier und die aktuelle Baudrate) und protokolliert die CAN-Messages via RS232-Schnittstelle an den PC. Ebenso wird immer die letzte Empfangene CAN-Message auf dem optionalen LCD anzgezeigt (empfohlen wird ein 2x24 Zeichen Textdisplay HD44780 kompatibel). Ebenso ist die Hardware in der Lage, CAN-Bus Messages selbst zu versenden (dies sollte man aber aus Sicherheitsgründen beim Motor-CAN nicht machen)
Kenndaten der Hardware:

• Mikrocontroller: ATMega 168
• 8-MHz Quarz
• CAN-Bus Controller: SJA 1000
• CAN-Bus Treiber: ATA 6660
• RS232 Schnittstelle: MAX232
• LCD-Schnittstelle für LCD-Displays (HD44780 kompatible) siehe Projekt LCD-Display
• CAN-Bus Schnittstelle ist nicht galvanisch getrennt
• ISP-Schnittstelle (zum Programmieren)
• JTAG-Schnittstelle (zum Programmieren und Debuggen via JTAG)
• Jumper für die Terminierung der CAN-Bus Leitungen wahlweise mit 120 bzw. 2,6k ohm
• Protokollierung der CAN-Messages via RS232 bzw. zum Senden von Steuerkommandos an den CAN-Analyzer

Hauptzweck der Schaltung ist es, in Fahrzeugen den CAN-Bus zu lokalisieren und zum analysieren der CAN-Messages

Software:
noch in der Mache :-)
Compiler: CodeVision AVR C

Programmierung:
Die Programmierung erfolgt via ISP Schnittstelle mit den üblichen Programmieradaptern, bzw. mit dem STK500 Entwicklungskit oder mittels JTAG-Interface

Fusesettings für den Atmel Prozessor:
- kommt noch

Schaltplan:

Bilder vom Prototypen Aufbau:

Leiterbahnunterseite vom Testaufbau:




Beispiel einer emfpangener Testmessage mit der CAN-ID 110 und 8 Datenbytes:

PI-CAN FD Duo - HAT-Modul

Hardware  (Version 0.1)

 Schaltplan

Die Schaltung besteht im Wesentlichen aus:

• 2 x MCP2517-FD -  CAN-Controller
• 2 x MCP2562-FD -  3,3V CAN-Bus Treibern
• 1 x EEPROM - HAT ID Eeprom 
• optionale Terminierung der CAN-Bus Leitungen mittels Jumper
• JP6 - Header : UART-Schnittstellen (console), so dass man den Raspi auch ohne Netzwerk über eine serielle Konsole konfigurieren kann.

Die CAN-Controller sind über den SPI-BUS an den Raspberry Pi angebunden und die SPI-Taktfrequenz beträgt 40MHz.

Hinweis: In dem Schaltplan sind für die Quarze jeweils zwei Bestückungsvarianten vorgesehen, so daß man die Bauform verwenden kann, die man gerade zur Hand hat, bzw. bei Handbestückung einfacher zu löten sind.

Schaltplan V0.1 PDF-Version

 Layout

 Aufbau

 
Abb.1.4  PI-CAN FD - Duo eingebaut

Abb.1.5  PI-CAN FD - Duo bestückte LP

..... in kürze mehr!

Die ersten Tests sahen schon sehr vielversprechend aus, d.h. das Senden und Empfangen von CAN-FD-Frames (auch mit Baudrate Switch) haben funktioniert.

Testsetup mit STM32 NUCLEO-G474-RE Board

Das Modul wurde mit dem Nucleo Board und diversen Baudraten getestet. Das verlinkte Video lief mit 1MHz Baudrate und 2 MHz Datenrate.

Meine CubeMx-Konfiguration:
images/pi_projekte/picanfd_duo/FD_Test.ioc

Es wird der FDCAN1 verwendet welcher dann direkt mit dem  CAN-FD Treiber MCP2561FD direkt verbunden ist ( mit flying wires). Dafür wird eine kleine Lochrasterkarte verwendet.

Ebenso wird der USART2 für die Debug-Ausgaben verwendet, da dieser hier im Nucleo Board über die USB-Buchse als VirtualComPort zur Verfügung gestellt wird, somit wird nur ein USB Anschluss und eine 5-6 V Versorgung benötigt.

Achtung: Dazu den Jumper auf +5V_VIN setzen (somit wird nur der intenre ST-Link mit Spannung versorgt). Und die Versorgungsspannung über Vin einspeisen

Eventuell ist dies  nicht notwendig und man kann alles über USB betreiben, aber dann wird der CAN-Treiber außerhalb seine Spezifikation von der Versorgungsspannung betrieben. (+5V für den CAN-Treiber).

Und hier ein kurzes Video welches die Funktion des Tests zeigt:

https://youtu.be/W887qp6XLx4

CAN0 wurde folgendermaßen konfiguriert:

pi@raspberrypi:~ $ sudo ip link set can0 up type can bitrate 1000000   dbitrate 2000000 restart-ms 1000 berr-reporting on fd on
pi@raspberrypi:~ $ 
pi@raspberrypi:~ $ ip -det link show can0
3: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 72 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 10
    link/can  promiscuity 0
    can <BERR-REPORTING,FD> state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 1000
          bitrate 1000000 sample-point 0.750
          tq 25 prop-seg 14 phase-seg1 15 phase-seg2 10 sjw 1
          mcp25xxfd: tseg1 2..256 tseg2 1..128 sjw 1..128 brp 1..256 brp-inc 1
          dbitrate 2000000 dsample-point 0.750
          dtq 25 dprop-seg 7 dphase-seg1 7 dphase-seg2 5 dsjw 1
          mcp25xxfd: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..256 dbrp-inc 1
          clock 40000000numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535

Tripple CAN-FD USB Dongle

Realsierung mit dem STM32G474-RB Prozessor.

.... in kürze ist hier mehr zu finden Sobald die Prototypen überprüft wurden.

Vorschau:

Bestückungsplan:

 Prototyp V1.0

Dieser Prototyp funktioniert auch ohne bestückten Quarz, d.h. der interne DFU-USB Bootloader und CAN-FD1 hatten auf Anhieb funktioniert. Ein kompletter Funktionstest, bei dem alle Hardware Module getestet werden, steht noch aus. Ebenso ist ja der Einsatz eines 24 MHz Quarz geplant. Für diesen Kurztest wurde der interne HSI verwendet und mittels PLL der System-Takt auf 160 MHz eingestellt. Die 160 MHz wurden gewählt, da dieser günstiger ist, um die üblichen CAN-Bus Baudraten einzustellen.

Hinweis: Der interne USB-Bootloader aktiviert den Ausgang PA6  (blaue LED). Dies hängt wohl damit zusammen, dass der interne SPI-Bootloader den PA6 als Ausgang konfiguriert. Mich wundert es etwas, dass diese Konfiguration nicht rückgängig gemacht wird, wenn der USB-Bootoader erkannt wird. Ist aber praktisch, da man jetzt automatisch eine Statusanzeige für den internen USB-Bootloader hat :-).  Und hier noch das Foto von meinem ersten Prototyp:

Abb.1.4 - Prototyp V1.0

Funktionstests

Die Tests wurden mit einer Testsoftware, die mit dem STM32CubeMX für den MDK-Keil erstellt wurde, durchgeführt.
Als 2. CAN-Device kam ein Raspberry Pi mit meinem Pi-CAN FD - Duo - HAT-Modul zum Einsatz bei dem der CAN0 mit: 

sudo ip link set can0 up type can bitrate 1000000   dbitrate 2000000 restart-ms 1000 berr-reporting on fd on

konfiguriert wurde.

Hier sind meine Testergebnisse:

• SWD Debug-Schnittstelle funktioniert.
• USART2 Debug Schnittstelle  inkl. (Retargeting) funktioniert
• USB-DFU Bootloader funktioniert
• Die Logik PB8-Boot0 und Jumper J1 muss nochmal überdacht, bzw. überarbeitet werden. Macht diese hier überhaupt Sinn wegen dem CAN-FD1 Treiber?
• CAN-FD1, CAN-FD2 und CAF-FD3  Rx und Tx mit den Baudraten:
  • nominal 1 MBit/s
  • Datenrate 2 MBit/s 
    getestet
• Ansteuerung der LEDs in Ordnung (Vorwiderstände wurden angepasst, s. V1.1)
  Hinweis: PA6 (blaue LED) wird vom interne DFU-USB Bootloader ebenfalls angesteuert.
• to dos:
  
  • weitere CAN-FD Baudraten testen
  • last, but not least,  die Firmware schreiben :-)

Für den ersten Test bei der alle 3 FDCANs verwendet werden, habe ich über die Debug-USART Schnittstelle die empfangenen Botschaften ausgegeben. Dabei wird von FDCAN2 die 0x111 Botschaft gesendet, die von FDCAN3 empfangen wird.  Und  der FDCAN1 empfängt die Botschaften die mein Raspberry Pi sendet:

#####################################
# Startup:
# HW: STM32-CANFD    
# SW: SW 1.0.0  (23:23:28 - Feb 19 2021)
#######################
# STM32G4:
# STM32 Device-ID: 0469  Revision: 2001
# Flash-Size: 128 kBytes
# Package = 00 (LQFP64)
# SN: 4500264752501820393855
#######################


[FDCAN3]         111  (BRS)  16   50 34 03 00 45 46 47 48 6E 65 77 4D 65 73 73 61
                                 
[FDCAN1]         7AF  (___)  64   60 1A 24 39 91 2B 11 77 60 1A 24 39 91 2B 11 77
                                  60 1A 24 39 91 2B 11 77 60 1A 24 39 91 2B 11 77
                                  60 1A 24 39 91 2B 11 77 60 1A 24 39 91 2B 11 77
                                  60 1A 24 39 91 2B 11 77 60 1A 24 39 91 2B 11 77
                                 
[FDCAN1]           C  (___)   5   BA E0 7C 56 10
[FDCAN1]         6FC  (___)   8   AA 11 79 04 85 B7 7F 2B
[FDCAN1]         6AD  (BRS)   2   A3 9B
[FDCAN3]         111  (BRS)  16   38 38 03 00 45 46 47 48 6E 65 77 4D 65 73 73 61
                                 
[FDCAN1]         47B  (___)   0  
[FDCAN1]   x12F2D3A3  (___)  20   61 C8 9F 53 40 C3 33 77 61 C8 9F 53 40 C3 33 77
                                  61 C8 9F 53
[FDCAN1]   x1192058C  (___)   0  
[FDCAN1]   x0057A18E  (___)   8   06 FD BF 1F 48 82 D4 36
[FDCAN1]         4E2  (___)   4   B8 7B F1 4A
[FDCAN3]         111  (BRS)  16   20 3C 03 00 45 46 47 48 6E 65 77 4D 65 73 73 61
                                 
[FDCAN1]          26  (___)   1   86
[FDCAN1]         4DF  (___)   4   40 52 B6 7A
[FDCAN1]   x19FFBCB3  (___)   8   D1 7F 14 0E 15 85 9F 4D
[FDCAN1]         3DE  (___)   1   2A
[FDCAN1]   x084209AB  (___)   8   85 1A 5A 45 B1 06 02 68
[FDCAN3]         111  (BRS)  16   08 40 03 00 45 46 47 48 6E 65 77 4D 65 73 73 61
                                 
[FDCAN1]         28E  (___)   3   E5 05 05
[FDCAN1]   x06F173B9  (BRS)  24   88 87 01 21 40 01 BD 27 88 87 01 21 40 01 BD 27
                                  88 87 01 21 40 01 BD 27
[FDCAN1]   x16C7A3C8  (___)   8   79 82 29 7A 09 F6 7D 31
[FDCAN1]   x118C8C6E  (___)   8   6F AC E0 2D 3F 0C A1 3F
[FDCAN1]   x010E04AA  (___)   8   72 C2 4E 38 D4 1F 3D 53
[FDCAN3]         111  (BRS)  16   F0 43 03 00 45 46 47 48 6E 65 77 4D 65 73 73 61
                                 
[FDCAN1]   x02366CFF  (BRS)   0  
[FDCAN3]         111  (BRS)  16   D8 47 03 00 45 46 47 48 6E 65 77 4D 65 73 73 61
                                 
[FDCAN3]         111  (BRS)  16   C0 4B 03 00 45 46 47 48 6E 65 77 4D 65 73 73 61
                                 
[FDCAN3]         111  (BRS)  16   A8 4F 03 00 45 46 47 48 6E 65 77 4D 65 73 73 61

Das ganze schaut mal sehr gut aus, somit müsste das mit dem CAN fürs Senden / Empfangen in Ordnung sein.
Zumal keine Botschaften verloren gehen.

Und hier noch ein kurzes Video von einem weiteren Test:

(https://youtu.be/Ao3T23NJt5g )


Hier noch das CubeMX Konfigurationsfile für den Protoypen. Das Keil-Projekt wurde noch nicht auf Github veröffentlicht (to do).
- FD_Test.ioc - Variante ohne USB und externen 24 MHz Quarz

Die geplante Konfiguration für alle 3 CAN-FDs, USB und Quarz sollte dann so aussehen:

Software

Wie oben schon erwähnt, wurde die Testsoftware mithilfe von STM32CubeMX  konfiguriert und als Keil-Projekt exportiert (s. o.  FD_Test.ioc )

CAN-FD Baudraten

Um günstige Werte für die CAN-Baudraten Berechnungen zu erhalten wurde der Systemtakt des Prozessors auf 160 MHz festgelegt (168 MHz wären auch gut :-) ).

Die Konfiguration im CubeMX erfolgt dann hier:

Obiges stellt die Baudrate auf  1 MBit/s (nominal) und 8 MBit/s Datenbaudrate ein. Der jeweilige Sampling-Point liegt bei 75%

Mithilfe meines Excels-Sheets ( fdcanBitrateCalculatorSTM32G4 - Wiki )habe ich mal folgende Einstellungen für die diversen Baudraten ermittelt und mit einem  PCAN-FD Interface getestet. Diese Werte gelten für einen Systemtakt von 160 MHz 
Ebenso wurden die Werte für einen Sampling-Point von 75% festgelegt:

• 250 kBit/s - Normale Baudrate (Es kommt zu Errors in Pcan-View)
  • Init.NominalPrescaler = 8;
  • Init.NominalSyncJumpWidth = 1;
  • Init.NominalTimeSeg1 = 59;
  • Init.NominalTimeSeg2 = 20;
• 500 kBit/s - Normale Baudrate
  • Init.NominalPrescaler = 4;
  • Init.NominalSyncJumpWidth = 1;
  • Init.NominalTimeSeg1 = 59;
  • Init.NominalTimeSeg2 = 20;
• 1 MBit - Normale Baudrate
  • Init.NominalPrescaler = 4;
  • Init.NominalSyncJumpWidth = 1;
  • Init.NominalTimeSeg1 = 29;
  • Init.NominalTimeSeg2 = 10;
• 2 MBit/s - Datenrate
  • Init.DataPrescaler = 4;
  • Init.DataSyncJumpWidth = 1;
  • Init.DataTimeSeg1 = 14;
  • Init.DataTimeSeg2 = 5;
• 4 MBit/s
  • Init.DataPrescaler = 1;
  • Init.DataSyncJumpWidth = 1;
  • Init.DataTimeSeg1 = 29;
  • Init.DataTimeSeg2 = 10;
• 8 MBit/s - (vereinzelte Stuffbit Fehler in PCAN-View)
  • Init.DataPrescaler = 1;
  • Init.DataSyncJumpWidth = 1;
  • Init.DataTimeSeg1 = 14;
  • Init.DataTimeSeg2 = 5;

Da es jeweils nur ein kurzer Test war, sind diese Werte erstmal unter Vorbehalt zu sehen. Weitere Tests werden noch folgen.

STM32-CAN – Hardware V1.2

 
     Abb. 1.1  STM32-CAN V1.2 Hardware

Hardware Modifikationen (L10009.02):

• Bugfix V-Bus  Signal  
• LED 3 (grün) hinzugefügt, dient jetzt als Rx-Status LED
• Low-Speed CAN-Bus jetzt fest auf SUB-D9.  (Pin 4 - CAN-LOW, Pin 9 - CAN-High)
  Somit kann das Interface mit einer speziellen Firmware als Gateway zwischen dem Low-Speed und High-Speed CAN-Bus eingesetzt werden.
  
  

Schaltplan:

Abb. 1.2 Schaltplan STM32-CAN Version V1.2

SUB-D9 Steckerbelegung (männlich):

Software:

Die neue Hardware wird ab den Softwareversionen V2.0.x  unterstützt. Wobei grundsätzlich auch die alte Version verwendet werden kann, allerdings wird dann die grüne LED nicht unterstützt.

Software V2.0.5 / V3.0.5:

• Senden und Empfangen von Remote Frames (RTR) hinzugefügt.
  (Die CANHacker Software macht aber kleine Anzeigefehler bei DLC > 0, getestet auch mit slcand)

Software V2.0.3 / V3.0.3:

• Benutzerdefinierte Baudrate für 47,619 kBaud (Saab-Fahrzeuge) hinzugefügt.
  ( Benutzerdefinierte Baudrate = 4762 )

Software V2.0.2 / V3.0.2:

• Benutzerdefinierte Baudrate von 95,234 kBaud  hinzugefügt.
  (Benutzerdefinierte Baudrate = 9500))
• Versionsnummer ab V3.x.x    (ab V3.0.2) ist die CAN-Hacker kompatible Variante die die Baudraten von:
  - 800 kBit
  - 1 Mit 
  unterstützt.

Software V2.0.1:

• Lawicel Protokoll um den Befehl F[CR] - Read Error Status erweitert
• CAN-Error Status abfragen (Vorerst wird nur das 'Bus Error (BEI)' Bit unterstützt! )
• Anzeige von CAN-Buss Error mittels synchronem Blinke aller LEDs.
  Ebenso wird beim Buserror die Read Error Status Meldung ohne Anforderung gesendet (maximal 1 mal pro Sekunde)

Software V2.0.0:

• Rx-Status, LED 3 (grün) toggeln wenn CAN-Botschaften empfangen werden
• Watchdog abgeschaltet
• CAN-Error Handling verbessert (ABOM auf enabled gesetzt)

 
Die neune Software Versionen sind auf der  STM32-CAN - Download Page  zu finden!     (nur registrierte Benutzer)

STM32CubeMX - Testprojekt für STM32-CAN

In Kürze werde ich hier eine kleine Anleitung für STM32CubeMX veröffentlichen, die beschreibt wie man meine Hardware mit dem CubeMX programmieren kann. Zur Kurzbeschreibung gehts hier:
STM32-CAN CubeMX - Projekt

Das CubeMX-Projekt ist hier: Github: STM32-CAN - CubeMX Testprojekt veröffentlicht.

Status (V0.3):
- LED ansteuern
- Lawcel Protokoll teilweise implementiert, so das der CAN-Hacker als CAN-Logger verwendet werden kann
- CAN TX-Message Testbotschaft  senden, beim Empfang (Lawicel)  zum Senden einer CAN-Botschaft
- Rx-Message empfangen (blaue LED wird getoggelt) und die Daten über Lawicel an den PC senden (CAN-Hacker zeigt
  die Botschaft im Monitor oer Trace-Fenster an)
- Normal Mode oder Listen Only Mode werden unterstützt
- Auswahl der Baudrate vom CAN-Hacker übernehmen

Status (V0.1):
- LED ansteuern
- CAN1 initialisiere  500 kBaud
- TX-Message senden
- Rx-Message empfangen (blaue LED wird getoggelt)

Wichtiger Hinweis für die Leute, die mein Protoypen-Board von mir erhalten haben:
Bitte nicht flashen, da sonst mein Bootloader überschrieben wird, und somit kein Firmware update mehr möglich ist.

Important not for the people who got my protoype interface from me:
Do not flash the interface, becaus my integrated bootloader will be erased, and so no further firmware upodates are possible.

Zur Zeit sind alle Prototypen V1.2 verkauft. Eventuell, wenn sich noch ein paar Interessenten finden, werde ich wieder welche fertigen lassen. Da ich aus Versehen die alte Version erneut gefertigt hatte, wird es die neue Version vorerst nicht geben. Allerdings muss zu erst der Restbestand von V1.1 aufgebraucht sein. 

für:
-  Deutschand: 25,-EUR inkl. Versand   (Brief)
-- Europa: 30,- EUR inkl. Versand (DHL Päckchen)
erwerben könnt. Wer kein PayPal verwenden will, kann mich auch über das Kontaktformular kontaktieren.

Der Lieferumfang entspricht obiger Abbildung Abb.1.1

Hinweise:
- Unversicherter Postversand
- Versand nur innerhalb der EU - Außerhalb der EU nur auf Anfrage
- Es handelt sich hierbei um einen Privatverkauf! 
- Die gesetzliche Gewährleistung wird hiermit ausgeschlossen. Der Käufer akzeptiert dies mit Klick auf den "Jetzt kaufen" Button
-  Das Interface wird vor dem Versand nochmal auf Funktion geprüft.

 Achtung: Prototypen von der 1. Version können weiterhin bezogen werden. Außer das in der ersten Version eine LED weniger bestückt ist und ein Bug-Fix von Hand korrigiert wurde haben beide Versionen den gleichen Funktionsumfang und funktionieren gleich gut.
Hier gehts zur Vorgänger Version:
"1.Prototypen Version V1.1"  PayPal Link: 1.Protoypen Version V1.1 jetzt kaufen