Hallo Leute! Ich versuche gerade auf einem Zynq 7030 den CAN-Controller zu verwenden. Die Tx und Rx-Leitungen sind auf die Pins U8 und U9 geroutet. Ich kann nur ein Frame abschicken und danach muss ich den Controller neu starten, um ein weiteres Frame zu schicken. Mit dem Oszilloskop hab ich die Tx-Leitung gemessen (Screenshot im Anhang). Die Bitrate ist auf 500.000 kbps gestellt. Mir kommt die Messung ziemlich eigenartig vor und das sieht mir nicht nach einem richtigen Frame aus. Kann mir da vielleicht einer weiterhelfen und erklären wo der Fehler sein kann?
Angehängte Dateien:
-
SCR03.PNG
8,3 KB
Fabian S. schrieb: > Ich kann > nur ein Frame abschicken und danach muss ich den Controller neu starten, > um ein weiteres Frame zu schicken. Hast Du denn jemanden am CAN Bus, der für den Frame ein ACKnowledge schickt? Ansonsten versucht ein CAN Controller immer wieder diesen Frame loszuwerden und nimmt keine neuen mehr entgegen. Der Screenshot sieht aber in der Tat seltsam aus. Schau Dir doch mal die Impulse genauer an. Vielleicht stimmt Deine Bitrateneinstellung nicht und das sind garkeine Impulse sondern ganze Frames. Mal abgesehen davon finde Ich die von Dir gewählte Timebase etwas seltsam. 100µs bei 2µs erwarteter Bitdauer.
:
Bearbeitet durch User
Angehängte Dateien:
-
SCR04.PNG
6,7 KB
Es gibt keinen anderen Teilnehmer und somit auch kein ACK. Als ich vor einiger Zeit mit dem Zybo gearbeitet habe, hat da der Controller solange ein ein Frame gesendet, bis ein ACK kommt. Vermutlich verhält es sich hier nicht so, weil anderer Zynq und anderes Linux-Image. Die 100µs kommen daher, damit man da den ganzen Signalverlauf sieht. Ich habe noch einen Screenshot mit 10µs/div. Die einzelnen Impulse sind einfach nur Impulse und keine Frames.
Timmo H. schrieb: > Was steht im Statusregister nach dem ersten Senden? Ich arbeite auf dem Zynq mit einem Linux-System. Gibt es da überhaupt die Möglichkeit das auszulesen? Wenn ja, wie? Vielleicht finde ich im /sys-Ordner etwas.
Wie sieht denn dein Device-Tree aus? Welche Tools benutzt du zum testen? Wie ist dein CAN-Bus elektrisch beschaltet?
Im Anhang gibt es den dekompilierten Device tree. Unten ist noch der Log vom Testen. Die Befehle und der Zustand sind gut erkennbar.
1 | root@elphel393:~# ip -details link show can0 |
2 | 2: can0: <NOARP,ECHO> mtu 16 qdisc noop state DOWN mode DEFAULT group default qlen 10 |
3 | link/can promiscuity 0 |
4 | can state SLEEPING (berr-counter tx 0 rx 0) restart-ms 0 |
5 | xilinx_can: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..256 brp-inc 1 |
6 | clock 999999990 |
7 | root@elphel393:~# ip link set can0 type can bitrate 500000 |
8 | root@elphel393:~# ip -details link show can0 |
9 | 2: can0: <NOARP,ECHO> mtu 16 qdisc noop state DOWN mode DEFAULT group default qlen 10 |
10 | link/can promiscuity 0 |
11 | can state SLEEPING (berr-counter tx 0 rx 0) restart-ms 0 |
12 | bitrate 499999 sample-point 0.875 |
13 | tq 250 prop-seg 3 phase-seg1 3 phase-seg2 1 sjw 1 |
14 | xilinx_can: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..256 brp-inc 1 |
15 | clock 999999990 |
16 | root@elphel393:~# ip link set can0 up |
17 | root@elphel393:~# ip -details link show can0 |
18 | 2: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 10 |
19 | link/can promiscuity 0 |
20 | can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0 |
21 | bitrate 499999 sample-point 0.875 |
22 | tq 250 prop-seg 3 phase-seg1 3 phase-seg2 1 sjw 1 |
23 | xilinx_can: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..256 brp-inc 1 |
24 | clock 999999990 |
25 | root@elphel393:~# cansend can0 404#09FA05 |
26 | root@elphel393:~# ip -details link show can0 |
27 | 2: can0: <NO-CARRIER,NOARP,UP,ECHO> mtu 16 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 10 |
28 | link/can promiscuity 0 |
29 | can state BUS-OFF (berr-counter tx 0 rx 0) restart-ms 0 |
30 | bitrate 499999 sample-point 0.875 |
31 | tq 250 prop-seg 3 phase-seg1 3 phase-seg2 1 sjw 1 |
32 | xilinx_can: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..256 brp-inc 1 |
33 | clock 999999990 |
34 | root@elphel393:~# dmesg | grep -i can |
35 | [ 2.970070] CAN device driver interface |
36 | [ 3.005079] can: controller area network core (rev 20120528 abi 9) |
37 | [ 3.015691] can: raw protocol (rev 20120528) |
38 | [ 3.020228] can: broadcast manager protocol (rev 20120528 t) |
39 | [ 3.025820] can: netlink gateway (rev 20130117) max_hops=1 |
40 | [ 187.472969] xilinx_can e0008000.can can0: bitrate error 0.0% |
Jetzt habe ich die Leitungen auf zwei andere Pins umgeleitet und bekomme ein anderes Signal heraus. Das Signal schaut besser aus, ist aber immer noch kein gültiges CAN-Signal. Am Anfang sieht es noch richtig aus (SCR07.PNG), aber dann wird es zum PWM-Signal mit doppelter Bitzeit. Das PWM-Signal bleibt solange (SCR06.PNG), bis die Rx-Leitung abgesteckt wird. Die Screenshots wurden mit halber Bitrate gemacht, aber bei der eigentlichen Bitrate schaut es gleich aus nur mit halben Bitzeiten.
Das PWM-Signal ist wahrscheinlich ein Wakeup-Symbol. Da keiner ein ACK für den Frame schickt, erkennt der Treiber BUS-OFF (siehe log) und versucht dann die anderen Teilnehmer aufzuwecken.
Martin H. schrieb: > Das PWM-Signal ist wahrscheinlich ein Wakeup-Symbol. Da keiner ein ACK > für den Frame schickt, erkennt der Treiber BUS-OFF (siehe log) und > versucht dann die anderen Teilnehmer aufzuwecken. Der Slot für das ACK von den Empfängern ist ja noch weiter hinten. Aber das hat mich dazu verleitet das Signal genauer anzuschauen. Mir ist nämlich aufgefallen, dass das Signal bis inkl. dem DLC-Feld richtig ist. Danach wird anscheinend das höherwertige Nibble vom ersten Datenbyte unendlich oft wiederholt. Die beiden Screenshots zeigen ein Frame mit der ID 0x5CB und einem Datenbyte. SCR09.PNG zeigt das Datenbyte 0x00 und man erkennt hier auch das Bit stuffing und SCR10.PNG zeigt das Datenbyte 0x5F, wo gut erkennbar ist, dass das zweite Nibble keinen Einfluss hat. Ich habe das mal mit verschiedenen Datenlängen ausprobiert und es macht keinen Unterschied. Ich vermute, dass der Treiber etwas falsch macht (Linux 4.0) und werde ihn mir heute genauer anschauen. Aber dass das Signal unendlich oft wiederholt wird, kann auch noch an der Hardware liegen. Weiß noch jemand, was da falsch sein kann, wenn es nicht am Treiber liegt? LG
Fabian S. schrieb: > Mir kommt die Messung ziemlich eigenartig vor und das sieht mir nicht > nach einem richtigen Frame aus. Kann mir da vielleicht einer > weiterhelfen und erklären wo der Fehler sein kann? Benutze auch ein Zybo und bekomme auch diesen Output (Pin MIO11), ohne andere Teilnehmer. Hast du den Grund dafür schon herausgefunden. Gruß Rüdiger
Rüdiger schrieb: > Fabian S. schrieb: >> Mir kommt die Messung ziemlich eigenartig vor und das sieht mir nicht >> nach einem richtigen Frame aus. Kann mir da vielleicht einer >> weiterhelfen und erklären wo der Fehler sein kann? > > Benutze auch ein Zybo und bekomme auch diesen Output (Pin MIO11), ohne > andere Teilnehmer. Hast du den Grund dafür schon herausgefunden. > > Gruß Rüdiger Rüdiger schrieb: > Mit xcanps_polled_example.c in XCANPS_MODE_NORMAL Überspringst du den SelfTest oder ist dieser bei dir erfolgreich? Hängt sich das Programm auf beim Wechsel vom Config mode zum Normal mode? Ich habe vorher schon einmal mit dem Zybo gearbeitet. Manchmal hilft es hier in Vivado alles aufzuräumen, Bitstream und Hardware neu zu exportieren und im SDK auch alles aufzuräumen. Wenn das nicht hilft, dann ein neues Projekt anlegen und alles neu erstellen. Hat bei mir so manches repariert.
Fabian S. schrieb: > Überspringst du den SelfTest oder ist dieser bei dir erfolgreich? > Hängt sich das Programm auf beim Wechsel vom Config mode zum Normal > mode? Der SelfTest war erfolgreich, wenn du den XCANPS_MODE_LOOPBACK meinst. Programm hängt sich nicht auf, sendet kontinuierlich den Output von deinem ersten angehängten screenshot. Wenn ich einen anderen MIO benutze sieht es auch so aus, leider.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.