CAN controller

[Romey-Rome]

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.

[msperl]

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)...

[msperl]

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

[Romey-Rome]

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 just tried this on a brand new pi2 & a clean build, and the result is exactly the same.

I'm still waiting for parts from Mouser to breadboard another CAN board to test. I will report back then.

[Romey-Rome]

Well. This one works, so must be my build.

http://www.ebay.com/itm/301524675333?_t ... EBIDX%3AIT

[Romey-Rome]

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

Yeey. New build works. Same schematic. I must have fried something the first time.

Thanks for taking the time to help!

[Romey-Rome]

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:

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.

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.

[msperl]

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)

[Romey-Rome]

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.

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

Guess I should just go plug it into the car & see what happens instead of trying this end-to-end thing.

[msperl]

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...

[sensationality]

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:

Code: Select all

mcp251x spi0.0: unable to set initial baudrate!
mcp251x spi0.0: can0: bit-timing not yet defined

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:

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

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.

[msperl]

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:

Code: Select all

/sbin/ip link set can0 up type can bitrate 500000

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)...

[MrBool]

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:

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!

It looks like hardware is fine. Do I need some other device on bus?

[msperl]

It looks like hardware is fine. Do I need some other device on bus?

same as the answer before - you need to configure the can-bus speed via:

Code: Select all

/sbin/ip link set can0 up type can bitrate 500000

You also need at least a second CAN device with identical bitrates configured on the CAN-BUS for communications to work - this is a "principle" of the can bus.

But 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

[MrBool]

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 ?

[msperl]

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.

[MrBool]

I use newest foundation kernels and I don't have problem with CAN drivers but tools like candump, cansend
etc. does not exist.

[msperl]

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:

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

then all the utils can get found in /usr/local/bin
and you are good to go

[chintan09]

I am currently seeing interface issues with PICAN and RPI2 board. Instead of seeing CNF message as,

Code: Select all

mcp251x spi0.0: CNF: 0x03 0xb5 0x01

This is the CNF message I was seeing.

Code: Select all

mcp251x spi0.0: CNF: 0x01 0xb5 0x01

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.

[msperl]

Assuming a 16MHz clock

• 01 b5 01 is configured for 500khz can-bus speed
• 03 b5 01 is configured for 250khz can-bus speed

So you have been using different bitrate parameter to get the different values.

You can also find the "typical" values with:

Code: Select all

can-calc-bit-timing -c 16000000 mcp251x

Which gives you the following table where you can also find these values you found:

Code: 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

[chintan09]

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

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)

Where as /proc/net/can/stats does show this message being sent.

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)

This is output of dmesg,

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

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.

[chintan09]

Adding more data point.

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

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

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

Do you guys think has the MCP251x driver hanged? Should I try with MCP2515 driver instead?

[msperl]

Well in principle things work, - the mcp251x is recognized and thus you can configure can0.

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.

The mcp251x had issues with 3.12 kernels when too many packets were sent in a short period of time, then the "reception" could get stuck, but there still would be a few interrupts and messages received, but they would stop in the middle.
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)

[nikkotorcita]

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

[msperl]

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

My long message got lost due to timeouts.

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.

The interrupt issue is gone with 3.18, so the main reason for not using mcp251x is gone.

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

As far as I can tell this gives you the best approach for your use-case.

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.