polybassa
commented
3 years ago Sorry, I can't help you in that case. --
Nils
On September 3, 2020 10:02:09 PM GMT+02:00, kestor notifications@github.com wrote:
I am evaluating Copperhills PiCAN FD Duo hat: https://copperhilltech.com/pican-fd-can-bus-fd-duo-board-with-real-time-clock-for-raspberry-pi/
Setup: I have looped back CAN-A to CAN-B and am running on a Pi-3. $ uname -a Linux raspberrypi 5.4.51-v7+ #1327 SMP Thu Jul 23 10:58:46 BST 2020 armv7l GNU/Linux
$ modinfo mcp25xxfd filename: /lib/modules/5.4.51-v7+/extra/mcp25xxfd.ko license: GPL v2 description: Microchip 25XXFD CAN driver author: Martin Sperl kernel@xxxxxxxxxxxxxxxx srcversion: 51E65DB89CFAC186E3213D0 alias: of:NTCmicrochip,mcp2517fdC alias: of:NT*Cmicrochip,mcp2517fd alias: spi:mcp2517fd depends: can-dev name: mcp25xxfd vermagic: 5.4.51-v7+ SMP mod_unload modversions ARMv7 p2v8
Operation:
CAN-A (can1) is set to dump packets $ candump can1
CAN-B (can0) sends a FD packet without BRS set $ cansend can0 003##0aabbccddeeff1122
CAN-A will receive the packet sent in step (2) can1 003 [64] AA BB CC DD EE FF 11 22
CAN-B (can0) sends a FD packet with BRS set $ cansend can0 003##1aabbccddeeff1122
CAN-A (can1) does not receive this correctly and the BUS errors.
Looking at the waveform on a scope I can see the arbitration bits look correct and I can see that the BRS is indeed set. However, immediately after the BRS is set the BUS is then in a recessive state for > 5 cycles with no bit stuff... bus errors at this point.
$ sudo ip --details --statistics link show can1 4: can1: <NOARP,UP,LOWER_UP,ECHO> mtu 72 qdisc pfifo_fast state UP mode DEFAULT group default qlen 65535 link/can promiscuity 0 minmtu 0 maxmtu 0 can
state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 1000 bitrate 1000000 sample-point 0.800 tq 25 prop-seg 15 phase-seg1 16 phase-seg2 8 sjw 1 mcp25xxfd: tseg1 2..256 tseg2 1..128 sjw 1..128 brp 1..256 brp-inc 1 dbitrate 1000000 dsample-point 0.800 dtq 25 dprop-seg 15 dphase-seg1 16 dphase-seg2 8 dsjw 1 mcp25xxfd: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..256 dbrp-inc 1 clock 40000000 re-started bus-errors arbit-lost error-warn error-pass bus-off 0 0 0 2 4 0
numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 RX: bytes packets errors dropped overrun mcast 1176 77 276553 0 0 0 TX: bytes packets errors dropped carrier collsns 544 68 0 2 0 0Please note that my dbitrate is the same as bitrate (i.e. 1mbps). It doesn't seem to matter what rate I pick the same behaviour occurs.
Current link set command used is: $ sudo ip link set can0 type can bitrate 1000000 sample-point 0.8 dbitrate 1000000 dsample-point 0.8 fd on
Just wondering if this is a driver issue (possible SPI?) or if I am missing something.
-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/polybassa/PICAN-DUO-FD-Raspberry-Pi/issues/1
sunscreen
I am evaluating Copperhills PiCAN FD Duo hat: https://copperhilltech.com/pican-fd-can-bus-fd-duo-board-with-real-time-clock-for-raspberry-pi/
Setup: I have looped back CAN-A to CAN-B and am running on a Pi-3. $ uname -a Linux raspberrypi 5.4.51-v7+ #1327 SMP Thu Jul 23 10:58:46 BST 2020 armv7l GNU/Linux
$ modinfo mcp25xxfd filename: /lib/modules/5.4.51-v7+/extra/mcp25xxfd.ko license: GPL v2 description: Microchip 25XXFD CAN driver author: Martin Sperl kernel@xxxxxxxxxxxxxxxx srcversion: 51E65DB89CFAC186E3213D0 alias: of:NTCmicrochip,mcp2517fdC alias: of:NT*Cmicrochip,mcp2517fd alias: spi:mcp2517fd depends: can-dev name: mcp25xxfd vermagic: 5.4.51-v7+ SMP mod_unload modversions ARMv7 p2v8
Operation:
CAN-A (can1) is set to dump packets $ candump can1
CAN-B (can0) sends a FD packet without BRS set $ cansend can0 003##0aabbccddeeff1122
CAN-A will receive the packet sent in step (2) can1 003 [64] AA BB CC DD EE FF 11 22
CAN-B (can0) sends a FD packet with BRS set $ cansend can0 003##1aabbccddeeff1122
CAN-A (can1) does not receive this correctly and the BUS errors.
Looking at the waveform on a scope I can see the arbitration bits look correct and I can see that the BRS is indeed set. However, immediately after the BRS is set the BUS is then in a recessive state for > 5 cycles with no bit stuff... bus errors at this point.
$ sudo ip --details --statistics link show can1 4: can1: <NOARP,UP,LOWER_UP,ECHO> mtu 72 qdisc pfifo_fast state UP mode DEFAULT group default qlen 65535 link/can promiscuity 0 minmtu 0 maxmtu 0 can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 1000
bitrate 1000000 sample-point 0.800
tq 25 prop-seg 15 phase-seg1 16 phase-seg2 8 sjw 1
mcp25xxfd: tseg1 2..256 tseg2 1..128 sjw 1..128 brp 1..256 brp-inc 1
dbitrate 1000000 dsample-point 0.800
dtq 25 dprop-seg 15 dphase-seg1 16 dphase-seg2 8 dsjw 1
mcp25xxfd: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..256 dbrp-inc 1
clock 40000000
re-started bus-errors arbit-lost error-warn error-pass bus-off
0 0 0 2 4 0 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
RX: bytes packets errors dropped overrun mcast
1176 77 276553 0 0 0
TX: bytes packets errors dropped carrier collsns
544 68 0 2 0 0
Please note that my dbitrate is the same as bitrate (i.e. 1mbps). It doesn't seem to matter what rate I pick the same behaviour occurs.
Current link set command used is: $ sudo ip link set can0 type can bitrate 1000000 sample-point 0.8 dbitrate 1000000 dsample-point 0.8 fd on
Just wondering if this is a driver issue (possible SPI?) or if I am missing something.