Re: CAN controller
Posted: Mon Mar 23, 2015 7:37 am
I get 255/0xff running it without any arguments, and 0/0x00 with the 7 arg. This is the same with or without the CAN board and GPIO7+GPIO9 shorted.
Raspberry Pi Forums
A small, affordable computer with free resources to help people learn, make things, and have fun
https://forums.raspberrypi.com/
CAN controller
Page 27 of 33
Re: CAN controller
Posted: Mon Mar 23, 2015 8:28 am
I have just checked - for me MISO/MOSI are typically low, so there must be something pulling it high on your end to result in 0xff to get read - especially if that ONLY happens with CS0 (=default) but you are reading 0x00 for CS1 (=argument 7)...
Re: CAN controller
Posted: Mon Mar 23, 2015 12:29 pm
Also it is important that the clock of the mcp2515 is running correctly!
Without a connected clock/crystal the mcp2515 will not respond on SPI and return 0x00 (or 0xff if you have added a pullup to MISO)...
So you may want to check that as well!
Martin
Without a connected clock/crystal the mcp2515 will not respond on SPI and return 0x00 (or 0xff if you have added a pullup to MISO)...
So you may want to check that as well!
Martin
Re: CAN controller
Posted: Fri Mar 27, 2015 5:09 am
I just tried this on a brand new pi2 & a clean build, and the result is exactly the same.msperl wrote:I have just checked - for me MISO/MOSI are typically low, so there must be something pulling it high on your end to result in 0xff to get read - especially if that ONLY happens with CS0 (=default) but you are reading 0x00 for CS1 (=argument 7)...
I'm still waiting for parts from Mouser to breadboard another CAN board to test. I will report back then.
Re: CAN controller
Posted: Fri Mar 27, 2015 11:41 pm
Re: CAN controller
Posted: Sat Mar 28, 2015 1:15 am
Yeey. New build works. Same schematic. I must have fried something the first time.msperl wrote:Also it is important that the clock of the mcp2515 is running correctly!
Without a connected clock/crystal the mcp2515 will not respond on SPI and return 0x00 (or 0xff if you have added a pullup to MISO)...
So you may want to check that as well!
Martin
Thanks for taking the time to help!
Re: CAN controller
Posted: Sat Mar 28, 2015 11:42 am
Well..something else now.
http://i.imgur.com/N7C6cYy.png
I have 2 Pis with a CAN on each. Both terminated with an R120.
Left in PiA, right is PiB.
Numbers are the order I executed the commands in. Top ones are dumps, bottom are the sends.
Nothing sent from B ever shows up on A.
A > B gets a frame error. As soon as I try a send from B > A, can0 interface just goes away with:
CanH/CanL voltages are in range, for what it's worth
Also, one end has a 16MHz crystal, and the other an 8Mhz. I've tried oscillator=16000000 & oscillator=8000000 with same results. Using bitrate 250000 on both ends.
http://i.imgur.com/N7C6cYy.png
I have 2 Pis with a CAN on each. Both terminated with an R120.
Left in PiA, right is PiB.
Numbers are the order I executed the commands in. Top ones are dumps, bottom are the sends.
Nothing sent from B ever shows up on A.
A > B gets a frame error. As soon as I try a send from B > A, can0 interface just goes away with:
Code: Select all
Mar 28 04:34:57 raspberrypi ifplugd(can0)[1614]: Link beat lost.
Mar 28 04:35:07 raspberrypi ifplugd(can0)[1614]: Executing '/etc/ifplugd/ifplugd.action can0 down'.
Mar 28 04:35:07 raspberrypi avahi-daemon[2279]: Withdrawing workstation service for can0.
Mar 28 04:35:07 raspberrypi ifplugd(can0)[1614]: Killing child.
Mar 28 04:35:07 raspberrypi ifplugd(can0)[1614]: Program execution failed, return value is 0.Also, one end has a 16MHz crystal, and the other an 8Mhz. I've tried oscillator=16000000 & oscillator=8000000 with same results. Using bitrate 250000 on both ends.
Re: CAN controller
Posted: Sat Mar 28, 2015 3:26 pm
Looks to me as if there is some missmatch in bit-clock-speeds, or a polarity issue on the bus or missing bus termination.
Anyway: I would recommend disabling ifplugd for the can interfaces to avoid the shutting down of the interface - look at /etc/default/ifplugd and modify HOTPLUG_INTERFACES to only include ethernet interfaces (no idea about what to include exactly)
Anyway: I would recommend disabling ifplugd for the can interfaces to avoid the shutting down of the interface - look at /etc/default/ifplugd and modify HOTPLUG_INTERFACES to only include ethernet interfaces (no idea about what to include exactly)
Re: CAN controller
Posted: Sun Mar 29, 2015 1:24 am
Well I got rid of can0 hot-plug by setting hotplug from "any" to "eth0"
can0 just goes to "can state BUS-OFF" now after the errors. Back up after ifconfig can0 down/up.
What effect does oscillator=16000000 have on anything? No matter what I set it to, clock always shows 8000000. I figured with oscillator=8000000, it would set the clock to 4000000?
Just to be clear, the A end is an 8Mhz crystal, and B end is a 16MHz.
Only time anything at all happens from A>B (ERRORFRAME) is when A is set to oscillator=16000000, even though it seems like it should be 8000000?
Bitrate makes no difference on the results.
Guess I should just go plug it into the car & see what happens instead of trying this end-to-end thing.
can0 just goes to "can state BUS-OFF" now after the errors. Back up after ifconfig can0 down/up.
What effect does oscillator=16000000 have on anything? No matter what I set it to, clock always shows 8000000. I figured with oscillator=8000000, it would set the clock to 4000000?
Just to be clear, the A end is an 8Mhz crystal, and B end is a 16MHz.
Only time anything at all happens from A>B (ERRORFRAME) is when A is set to oscillator=16000000, even though it seems like it should be 8000000?
Bitrate makes no difference on the results.
Code: Select all
root@raspberrypi:~# ip -d link show can0
3: can0: <NO-CARRIER,NOARP,UP,ECHO> mtu 16 qdisc pfifo_fast state DOWN mode DEFAULT qlen 10
link/can
can state BUS-OFF restart-ms 0
bitrate 500000 sample-point 0.875
tq 125 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1
mcp251x: tseg1 3..16 tseg2 2..8 sjw 1..4 brp 1..64 brp-inc 1
clock 8000000
Re: CAN controller
Posted: Sun Mar 29, 2015 8:05 am
Oscillator is defining the Quartz/resonator on your board.
The ip command unfortunately shows this value divided by 2.
So the oscillator setting is fixed by your setup.
This value needs to get set in your device-tree as a parameter when loading the overlay via /boot/config.txt.
The can-bus bitrate you set with the ip command - these should be identical for a working communication - otherwise you will get those error-frames on the receiver side and the sender will go into error mode
The oscillator is used as the base-clock for the real bit-rate and a divider is calculated based on this and the requested bit-rate for the bus to make it work.
So assuming you got identical setups on both rpis you should have identical configs for oscillator and bitrate on both rpis and then the communication should work.
Again: you need some termination on the can bus - 120 ohm between can-high and low at both ends if that is not the case you may get reflections and that could also produce error frames when the checksums are incorrect...
The ip command unfortunately shows this value divided by 2.
So the oscillator setting is fixed by your setup.
This value needs to get set in your device-tree as a parameter when loading the overlay via /boot/config.txt.
The can-bus bitrate you set with the ip command - these should be identical for a working communication - otherwise you will get those error-frames on the receiver side and the sender will go into error mode
The oscillator is used as the base-clock for the real bit-rate and a divider is calculated based on this and the requested bit-rate for the bus to make it work.
So assuming you got identical setups on both rpis you should have identical configs for oscillator and bitrate on both rpis and then the communication should work.
Again: you need some termination on the can bus - 120 ohm between can-high and low at both ends if that is not the case you may get reflections and that could also produce error frames when the checksums are incorrect...
Re: CAN controller
Posted: Mon Apr 06, 2015 4:36 am
Hi all,
I've read through this thread and saw great help, so I made a design for CAN on the RPi 2, BUT I'm having an issue.
I've followed all the steps for setup of the pi2: http://skpang.co.uk/blog/archives/1165
Following this, I can see my can0 in ifconfig -a, and I see can-dev, mcp251x, and spi in "less /proc/modules". I can send (./cansend) messages without any error, but they dont show on the CAN Analyzer. Also, when I run "dmesg | less", after starting up I constantly see this error:
I'm confident my hardware is correct, I've tested it with an oscilloscope, and I've run the script mentioned on the previous page to test MCP with this (correct) output:
I'm not sure where the problem could lie. Why can't it set the bitrate? Any help is appreciated.
PS: I found this potential fix for the same problem here: http://www.spinics.net/lists/netdev/msg113104.html
It says to modify mcp251x.c file to set the baud rate, but I can't find this file anywhere on my system! So I'm not sure where I can modify it.
I've read through this thread and saw great help, so I made a design for CAN on the RPi 2, BUT I'm having an issue.
I've followed all the steps for setup of the pi2: http://skpang.co.uk/blog/archives/1165
Following this, I can see my can0 in ifconfig -a, and I see can-dev, mcp251x, and spi in "less /proc/modules". I can send (./cansend) messages without any error, but they dont show on the CAN Analyzer. Also, when I run "dmesg | less", after starting up I constantly see this error:
Code: Select all
mcp251x spi0.0: unable to set initial baudrate!
mcp251x spi0.0: can0: bit-timing not yet definedCode: Select all
Resetting MCP2515
RESET 0 0x00
Read MCP2515 registers
CMD-READ 0 0x00
REG-CNF3 0 0x00
CNF3 0 0x00
CNF2 0 0x00
CNF1 0 0x00
INTE 0 0x00
INTF 0 0x00
EFLG 0 0x00
CANSTAT 128 0x80
CANCTRL 135 0x87PS: I found this potential fix for the same problem here: http://www.spinics.net/lists/netdev/msg113104.html
It says to modify mcp251x.c file to set the baud rate, but I can't find this file anywhere on my system! So I'm not sure where I can modify it.
Re: CAN controller
Posted: Mon Apr 06, 2015 1:56 pm
The message signifies that the HW itself is recognized correctly.
It just means you need to do the final setup step to configure the baud rate on the bus, which is dependent on your use-case.
To set the bit-rate to 500khz you need to run the following:
Then those messages will stop and you should be able to transmit/receive messages on the CAN bus...
Still you will need to know what the bitrate is for your can-bus and you may not receive data unless you
send some data first (at least for some cars I heard that that is the case)...
It just means you need to do the final setup step to configure the baud rate on the bus, which is dependent on your use-case.
To set the bit-rate to 500khz you need to run the following:
Code: Select all
/sbin/ip link set can0 up type can bitrate 500000Still you will need to know what the bitrate is for your can-bus and you may not receive data unless you
send some data first (at least for some cars I heard that that is the case)...
Re: CAN controller
Posted: Tue Apr 07, 2015 7:53 am
I'm trying to communicate two raspberry by CAN bus. I'm using PICAN CAN-Bus board. On both raspberry I don't see /dev/can0 and dmesg show me:
It looks like hardware is fine. Do I need some other device on bus?
Code: Select all
[ 11.449421] spi_config_register: device description: bus=0:cs=0:modalias=mcp2515:speed=10000000:gpioirq=25:pd=20:pdu32-0=12000000:pdu32-4=0x2002:force_release
[ 11.466501] spi_config_match_cs: SPI0: check CS=0 to be 0
[ 11.473364] spi_config_match_cs: SPI0.0: Found a device with modinfo spidev
[ 11.481881] spi_config_register:spi0.0:mcp2515: found already registered device
[ 11.490703] spi_config_register:spi0.0:mcp2515: forcefully-releasing already registered device taints kernel
[ 11.506503] spi_config_register:spi0.0: registering modalias=mcp2515 with max_speed_hz=10000000 mode=0 and gpio/irq=25/195
[ 11.536253] spi_config_register:spi0.0:platform data:da2e3900: 00 1b b7 00 02 20 00 00 00 00 00 00 00 00 00 00 ..... ..........
[ 11.567949] spi_config_register:spi0.0:platform data:da2e3910: 00 00 00 00 ....
[ 11.596663] CAN device driver interface
[ 11.707507] mcp251x spi0.0: probed
[ 20.234327] mcp251x spi0.0 can0: bit-timing not yet defined
[ 20.234367] mcp251x spi0.0: unable to set initial baudrate!
[ 20.234773] mcp251x spi0.0 can0: bit-timing not yet defined
[ 20.234800] mcp251x spi0.0: unable to set initial baudrate!
[ 20.234852] mcp251x spi0.0 can0: bit-timing not yet defined
[ 20.234869] mcp251x spi0.0: unable to set initial baudrate!
Re: CAN controller
Posted: Tue Apr 07, 2015 9:12 am
same as the answer before - you need to configure the can-bus speed via:MrBool wrote:It looks like hardware is fine. Do I need some other device on bus?
Code: Select all
/sbin/ip link set can0 up type can bitrate 500000But note that afaik PICAN comes with a 16MHz oscillator, but your config shows that you have configured a 12MHz oscillator.
In general would recommend that you start using the new foundation kernels and the foundation-provided device-tree overlays as described in an earlier post.
essentially:
- rpi-update
- edit /boot/config.txt adding:
Code: Select all
dtoverlay=spi-bcm2835-overlay dtoverlay=mcp2515-can0-overlay - reboot
- run the following after every boot:
Code: Select all
/sbin/ip link set can0 up type can bitrate 500000
Re: CAN controller
Posted: Wed Apr 08, 2015 7:29 am
Msperl, thank you. It works now.
I'm using now 3.12.28 kernel and modules from http://ifinterface.com/page/page3.php?langid=1
If I want to use newest foundation kernels do I have to compile kernel CAN modules and load them during boot or I just have to add "dtoverlay=mcp2515-can0-overlay" to /boot/config.txt ?
I'm using now 3.12.28 kernel and modules from http://ifinterface.com/page/page3.php?langid=1
If I want to use newest foundation kernels do I have to compile kernel CAN modules and load them during boot or I just have to add "dtoverlay=mcp2515-can0-overlay" to /boot/config.txt ?
Re: CAN controller
Posted: Wed Apr 08, 2015 7:54 am
The foundation kernels now come with can and mcp251x drivers compiled in.
But you only get those updates only if you update via rpi-update.
But you only get those updates only if you update via rpi-update.
Re: CAN controller
Posted: Wed Apr 08, 2015 4:17 pm
I use newest foundation kernels and I don't have problem with CAN drivers but tools like candump, cansend
etc. does not exist.
etc. does not exist.
Re: CAN controller
Posted: Wed Apr 08, 2015 4:39 pm
That is the only thing you have to get from somewhere else unfortunately...
I still wonder why there is no package to install those automatically in wheezy.
The next debian contains such a package.
but in principle it works like this:
then all the utils can get found in /usr/local/bin
and you are good to go
I still wonder why there is no package to install those automatically in wheezy.
The next debian contains such a package.
but in principle it works like this:
Code: Select all
git clone https://git.gitorious.org/linux-can/can-utils.git
make -C can-utils
sudo make -C can-utils install PREFIX=/usr/local
rm -rf can-utils
and you are good to go
Re: CAN controller
Posted: Thu Apr 09, 2015 4:46 am
I am currently seeing interface issues with PICAN and RPI2 board. Instead of seeing CNF message as,
This is the CNF message I was seeing.
Digging deeper, struct can_bittiming, brp field was not set correctly. Does any one have any insight on this? I followed all the instructions from this blog article http://skpang.co.uk/blog/archives/1165.
Thanks.
Code: Select all
mcp251x spi0.0: CNF: 0x03 0xb5 0x01Code: Select all
mcp251x spi0.0: CNF: 0x01 0xb5 0x01Thanks.
Re: CAN controller
Posted: Thu Apr 09, 2015 8:48 pm
Assuming a 16MHz clock
You can also find the "typical" values with:
Which gives you the following table where you can also find these values you found:
- 01 b5 01 is configured for 500khz can-bus speed
- 03 b5 01 is configured for 250khz can-bus speed
You can also find the "typical" values with:
Code: Select all
can-calc-bit-timing -c 16000000 mcp251xCode: Select all
Bit timing parameters for mcp251x with 16.000000 MHz ref clock
nominal real Bitrt nom real SampP
Bitrate TQ[ns] PrS PhS1 PhS2 SJW BRP Bitrate Error SampP SampP Error CNF1 CNF2 CNF3
1000000 62 5 6 4 1 1 1000000 0.0% 75.0% 75.0% 0.0% 0x00 0xac 0x03
800000 62 7 8 4 1 1 800000 0.0% 80.0% 80.0% 0.0% 0x00 0xbe 0x03
500000 125 6 7 2 1 2 500000 0.0% 87.5% 87.5% 0.0% 0x01 0xb5 0x01
250000 250 6 7 2 1 4 250000 0.0% 87.5% 87.5% 0.0% 0x03 0xb5 0x01
125000 500 6 7 2 1 8 125000 0.0% 87.5% 87.5% 0.0% 0x07 0xb5 0x01
100000 625 6 7 2 1 10 100000 0.0% 87.5% 87.5% 0.0% 0x09 0xb5 0x01
50000 1250 6 7 2 1 20 50000 0.0% 87.5% 87.5% 0.0% 0x13 0xb5 0x01
20000 3125 6 7 2 1 50 20000 0.0% 87.5% 87.5% 0.0% 0x31 0xb5 0x01
10000 4000 8 8 8 1 64 10000 0.0% 87.5% 68.0% 22.3% 0x3f 0xbf 0x07
Re: CAN controller
Posted: Thu Apr 09, 2015 9:49 pm
Thanks @msperl, now I understand the change in CNF values.
I am still facing problems with sending OBD2 commands to an ECU. Even though I send a request through cansend, I don't see that message being counted towards tx message. It's all zero in ifconfig can0 entry
Where as /proc/net/can/stats does show this message being sent.
This is output of dmesg,
Also one more datapoint, for some reason when setting can in loopback mode, I wasn't seeing any message sent via cansend on other terminal's candump output.
The setup is, RPI2 board (Linux rpi 3.18.8-v7 #8 SMP PREEMPT Thu Apr 9 12:47:47 PDT 2015 armv7l GNU/Linux) + CANPI HAT. Thank you for looking.
I am still facing problems with sending OBD2 commands to an ECU. Even though I send a request through cansend, I don't see that message being counted towards tx message. It's all zero in ifconfig can0 entry
Code: Select all
# ifconfig can0
can0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
UP RUNNING NOARP MTU:16 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:10
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Code: Select all
# cat /proc/net/can/stats
6 transmitted frames (TXF)
0 received frames (RXF)
0 matched frames (RXMF)
0 % total match ratio (RXMR)
0 frames/s total tx rate (TXR)
0 frames/s total rx rate (RXR)
0 % current match ratio (CRXMR)
0 frames/s current tx rate (CTXR)
0 frames/s current rx rate (CRXR)
0 % max match ratio (MRXMR)
1 frames/s max tx rate (MTXR)
0 frames/s max rx rate (MRXR)
0 current receive list entries (CRCV)
0 maximum receive list entries (MRCV)
Code: Select all
# dmesg | egrep "can|spi|mcp"
[ 0.187938] bus: 'spi': registered
[ 0.187952] device class 'spi_master': registering
[ 0.189276] device: '3f204000.spi': device_add
[ 0.189307] bus: 'platform': add device 3f204000.spi
[ 0.189852] device: 'clocks:can0_osc': device_add
[ 0.189883] bus: 'platform': add device clocks:can0_osc
[ 1.679987] device class 'spidev': registering
[ 1.680031] bus: 'spi': add driver spidev
[ 1.680124] bus: 'platform': add driver spi-bcm2835
[ 1.680180] bus: 'platform': driver_probe_device: matched device 3f204000.spi with driver spi-bcm2835
[ 1.680194] bus: 'platform': really_probe: probing driver spi-bcm2835 with device 3f204000.spi
[ 1.680467] device: 'spi0': device_add
[ 1.680592] spi-bcm2835 3f204000.spi: registered master spi0
[ 1.681437] spi spi0.0: setup mode 0, 8 bits/w, 10000000 Hz max --> 0
[ 1.681458] device: 'spi0.0': device_add
[ 1.681498] bus: 'spi': add device spi0.0
[ 1.681594] spi-bcm2835 3f204000.spi: registered child spi0.0
[ 1.681918] spi spi0.1: setup mode 0, 8 bits/w, 500000 Hz max --> 0
[ 1.681935] device: 'spi0.1': device_add
[ 1.681972] bus: 'spi': add device spi0.1
[ 1.682063] bus: 'spi': driver_probe_device: matched device spi0.1 with driver spidev
[ 1.682078] bus: 'spi': really_probe: probing driver spidev with device spi0.1
[ 1.682106] spidev spi0.1: no default pinctrl state
[ 1.682162] device: 'spidev0.1': device_add
[ 1.682384] driver: 'spidev': driver_bound: bound to device 'spi0.1'
[ 1.682403] bus: 'spi': really_probe: bound device spi0.1 to driver spidev
[ 1.682424] spi-bcm2835 3f204000.spi: registered child spi0.1
[ 1.682439] driver: 'spi-bcm2835': driver_bound: bound to device '3f204000.spi'
[ 1.682454] bus: 'platform': really_probe: bound device 3f204000.spi to driver spi-bcm2835
[ 1.682583] bus: 'platform': add driver bcm2708_spi
[ 1.682692] bus: 'platform': remove driver bcm2708_spi
[ 1.682729] driver: 'bcm2708_spi': driver_release
[ 1.682779] vcan: Virtual CAN interface driver
[ 1.694500] bus: 'spi': add driver mcp251x
[ 1.694544] bus: 'spi': driver_probe_device: matched device spi0.0 with driver mcp251x
[ 1.694558] bus: 'spi': really_probe: probing driver mcp251x with device spi0.0
[ 1.694703] mcp251x spi0.0: setup mode 0, 8 bits/w, 10000000 Hz max --> 0
[ 1.704928] mcp251x spi0.0: CANCTRL 0x87
[ 1.705031] device: 'can0': device_add
[ 1.705862] driver: 'mcp251x': driver_bound: bound to device 'spi0.0'
[ 1.705881] bus: 'spi': really_probe: bound device spi0.0 to driver mcp251x
[ 2.479885] can: controller area network core (rev 20120528 abi 9)
[ 2.494504] can: raw protocol (rev 20120528)
[ 2.525054] can: broadcast manager protocol (rev 20120528 t)
[ 2.525090] can: netlink gateway (rev 20130117) max_hops=1
[ 103.234965] mcp251x spi0.0: CNF: 0x01 0xb5 0x01
The setup is, RPI2 board (Linux rpi 3.18.8-v7 #8 SMP PREEMPT Thu Apr 9 12:47:47 PDT 2015 armv7l GNU/Linux) + CANPI HAT. Thank you for looking.
Re: CAN controller
Posted: Fri Apr 10, 2015 9:21 pm
Adding more data point.
Looks like interrupt's for mcp251x not firing.
Strange thing is that this setup did work briefly with CANPI but has stopped working now. With the bit banging SPI, I could still read the registers on MCP
Do you guys think has the MCP251x driver hanged? Should I try with MCP2515 driver instead?
Looks like interrupt's for mcp251x not firing.
Code: Select all
# cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3
16: 0 0 0 0 ARMCTRL 16 bcm2708_fb dma
32: 397170 0 0 0 ARMCTRL 32 dwc_otg, dwc_otg_pcd, dwc_otg_hcd:usb1
49: 0 0 0 0 ARMCTRL 49 3f200000.gpio:bank0
50: 0 0 0 0 ARMCTRL 50 3f200000.gpio:bank1
65: 11 0 0 0 ARMCTRL 65 ARM Mailbox IRQ
66: 2 0 0 0 ARMCTRL 66 VCHIQ doorbell
75: 1 0 0 0 ARMCTRL 75
80: 38 0 0 0 ARMCTRL 80 3f204000.spi
84: 1024553 0 0 0 ARMCTRL 84 mmc0
99: 9020 9607 4135 379 ARMCTRL 99 arch_timer
473: 0 0 0 0 pinctrl-bcm2835 25 mcp251x
FIQ: usb_fiq
IPI0: 0 0 0 0 CPU wakeup interrupts
IPI1: 0 0 0 0 Timer broadcast interrupts
IPI2: 3046 1848 2870 461 Rescheduling interrupts
IPI3: 2 2 4 3 Function call interrupts
IPI4: 1 1 0 0 Single function call interrupts
IPI5: 0 0 0 0 CPU stop interrupts
IPI6: 0 0 0 0 IRQ work interrupts
IPI7: 0 0 0 0 completion interrupts
Err: 0
Code: Select all
Resetting MCP2515
RESET 0 0x00
Read MCP2515 registers
CMD-READ 0 0x00
REG-CNF3 0 0x00
CNF3 0 0x00
CNF2 0 0x00
CNF1 0 0x00
INTE 0 0x00
INTF 0 0x00
EFLG 0 0x00
CANSTAT 128 0x80
CANCTRL 135 0x87
Re: CAN controller
Posted: Sat Apr 11, 2015 6:57 am
Well in principle things work, - the mcp251x is recognized and thus you can configure can0.
I see 2 possible reasons:
With 3.18 kernels that is not the case any longer and also the reliability is much improved - I am running 2 mcp2515s concurrently listening on the can bus and each one has received 5M can-messages (back to back) so far without any issues (besides some missed packets, but that is related to latencies on the SPI bus)
I see 2 possible reasons:
- you have configured the wrong bitrate for the bus you are connected to - you have been initially been confused about 500kHz or 250kHz, so I wonder if you are using the right parameters. Still - you should receive some error packets in such cases, which would also increase interrupt counts.
- someone said on this forum before, that some cars have some sort of "gatekeeper" on the OBD2 interface. So you only get data when you query the bus. This means you might have to run a query to see anything.
With 3.18 kernels that is not the case any longer and also the reliability is much improved - I am running 2 mcp2515s concurrently listening on the can bus and each one has received 5M can-messages (back to back) so far without any issues (besides some missed packets, but that is related to latencies on the SPI bus)
Re: CAN controller
Posted: Sun Apr 12, 2015 3:11 pm
Hi msperl!
I've been following your development of an improved SPI driver with DMA for the Pi as well as your mcp2515a driver and it's been very helpful! I'm developing a sensor system that has at least 8 CAN nodes that need to run at full 1mbit/s speed. There is a case where I need to broadcast >5M of data to all of the nodes but I'm encountering a problem where the transmission stalls (I'm using the 3.11.2+ kernel btw) and I'm assuming this is due to the interrupt issue you mentioned in the previous posts. So my questions are:
1. What's the difference between your latest 2515a from https://github.com/msperl/mcp2515a and the mcp251x in the foundation kernel?
2. Which one would you recommend for use in my case? And if ever it's your mcp2515a, which kernel branch should I apply your spi-optimize.patch to?
Thanks so much for all the hardware on RPi's SPI and the CAN driver!
Cheers
I've been following your development of an improved SPI driver with DMA for the Pi as well as your mcp2515a driver and it's been very helpful! I'm developing a sensor system that has at least 8 CAN nodes that need to run at full 1mbit/s speed. There is a case where I need to broadcast >5M of data to all of the nodes but I'm encountering a problem where the transmission stalls (I'm using the 3.11.2+ kernel btw) and I'm assuming this is due to the interrupt issue you mentioned in the previous posts. So my questions are:
1. What's the difference between your latest 2515a from https://github.com/msperl/mcp2515a and the mcp251x in the foundation kernel?
2. Which one would you recommend for use in my case? And if ever it's your mcp2515a, which kernel branch should I apply your spi-optimize.patch to?
Thanks so much for all the hardware on RPi's SPI and the CAN driver!
Cheers
Re: CAN controller
Posted: Sun Apr 12, 2015 6:03 pm
My long message got lost due to timeouts.nikkotorcita wrote:Hi msperl!
I've been following your development of an improved SPI driver with DMA for the Pi as well as your mcp2515a driver and it's been very helpful! I'm developing a sensor system that has at least 8 CAN nodes that need to run at full 1mbit/s speed. There is a case where I need to broadcast >5M of data to all of the nodes but I'm encountering a problem where the transmission stalls (I'm using the 3.11.2+ kernel btw) and I'm assuming this is due to the interrupt issue you mentioned in the previous posts. So my questions are:
1. What's the difference between your latest 2515a from https://github.com/msperl/mcp2515a and the mcp251x in the foundation kernel?
2. Which one would you recommend for use in my case? And if ever it's your mcp2515a, which kernel branch should I apply your spi-optimize.patch to?
Thanks so much for all the hardware on RPi's SPI and the CAN driver!
Cheers
Short:
Driver-difference:
- mcp251x: uses spi-synchronous interface - had issues with 3.12 interrupt handling resulting in the driver stalling
- mcp251x: uses spi-asyncronous interface - works around those interrupt issues in 3.12 and also tries to optimize for an optimized spi driver.
Recommendation:
- use RPI2
- use the 3.18 kernel that comes with it
- use the mcp251x configuring the the dt-overlay
- use the spi-bcm2835 configuring the the dt-overlay
Due to the design of the mcp2515 with its 2 reception buffers there is still a chance to loose CAN-messages, because those two buffers may fill faster than the rpi can read those buffers.
Worsted case a CAN message may arrive every 47us ("standard" ids, 0 bytes at 1MHz), so the rpi ideally has to handle the message in that time otherwise it will fill the second buffer and if that is not handled in sufficient time then there is packet-loss.
This becomes more dominant with a 1MHz CAN-bus
So you have to weight these parameters in your design.