Forum: FPGA, VHDL & Co. Kaputter CAN am Zynq


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Fabian S. (fsasm)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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?

von Martin H. (mahi)


Bewertung
0 lesenswert
nicht lesenswert
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
von Fabian S. (fsasm)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

von Timmo H. (masterfx)


Bewertung
0 lesenswert
nicht lesenswert
Was steht im Statusregister nach dem ersten Senden?

von Fabian S. (fsasm)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Timmo H. (masterfx)


Bewertung
0 lesenswert
nicht lesenswert
Wie sieht denn dein Device-Tree aus?
Welche Tools benutzt du zum testen? Wie ist dein CAN-Bus elektrisch 
beschaltet?

von Fabian S. (fsasm)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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%

von Fabian S. (fsasm)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

von Martin H. (mahi)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Fabian S. (fsasm)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

von Rüdiger (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Rüdiger (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Mit xcanps_polled_example.c in XCANPS_MODE_NORMAL

von Fabian S. (fsasm)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Rüdiger (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.