CAN controller

[xxethanixx]

After messing around, I found out I needed to use the following command to bring up the link:

ip link set can0 type can bitrate 125000 loopback on
(I changed the bitrate just for testing)

Additionally, I used your suggestion and created a simple shell script to bring down/up the device which accepts an argument being that of the bitrate in which you want, to make things easier. Seems as this is the best way for me right now!

Everything seems to be working as expected. Finally!!

root@raspberrypi:~# cansend can0 123#5448414e4b594f550a
root@raspberrypi:~# cansend can0 123#4d617274696e0a


root@raspberrypi:~# candump -td -cae can0,0:0,#FFFFFFFF
(000.000990) can0 123 [8] 54 48 41 4E 4B 59 4F 55 'THANKYOU'
(032.486897) can0 123 [7] 4D 61 72 74 69 6E 0A 'Martin.'

-Ethan

[xxethanixx]

Okay so after all that fun configuration and headaches, I was finally able to take the time and hookup my pi to the obdII shell with CAN_H on pin 6 and CAN_L on pin 14. After that, I started up the canbus, and set the baud rate to 500000 (500kb). Finally I thought I was going to be able to listen in on my 2014 chevy cruze canbus. Unfortunately, I didn't get one singe message I even attempted to change the baud rate around to make sure it wasnt something stupid, but I was still unsuccessful.

Has anyone been successful in actually capturing data from vehicles CANBUS? I did some searching around, but didnt find much about my specific make/model/year of car. Hopefully I will be able to figure this out, I'm starting to pull my hair out!!

[msperl]

@xxethanixx: no idea what that could be - maybe reverse polarity/wrong wireing/wrong clock speeds.
It really would require a logic analyzer here to see what is happening...

[msperl]

Note that the next kernel by the foundation will finally contain the mcp251x driver compiled in.
Also there is now an overlay to make things work
Essentially add the following to your /boot/config.txt:

Code: Select all

dtparam=spi=on
dtoverlay=mcp2515-can0-overlay,oscillator=16000000,interrupt=25

You may optionally also load the upstream can driver:

Code: Select all

dtoverlay=spi-bcm2835-overlay

And reboot and everything should be working fine the required modules are loaded and you only need to configure the interface itself:

Code: Select all

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

Now the only thing missing are those can-utils...

Hope this makes your life easier!

Martin

[bapou]

Hi Martin

I try to get the CAN-BUS / mcp251x to work on a Raspberry Pi 2 Model B.
On the previous model I used the precompiled kernel
from http://lnxpps.de/rpie/rpi-can-3.12.28+.tar.bz2 and everything worked find.

Your last posts sounds as we don't need this anymore? Thus in a
Raspberry Pi 2 Model B, using an a completely updated system I tried your technique,
added the lines to the /boot/config.txt, rebooted
and /sbin/ip link set can0 up type can bitrate 500000

However, I get: "Cannot find device "can0"

Is there anything missing or is this only working after the next kernel includes the mcp25X driver?

Thanks,
Thom

[msperl]

Hi Martin
Is there anything missing or is this only working after the next kernel includes the mcp25X driver?

you might need the latest firmware installed - but checking shows that there has not been an update to the firmware over the last few days, so it might not be fully ready (i was hoping that would have happened already).

So check for new updates over the next few days via rpi-update and it should show up at some point.
you can also check if the file /boot/overlays/mcp2515-can0-overlay.dtb exists and then it should be supported.

[bapou]

Thanks! This will really simplify the use of CAN with the RPI.

[HaMaMoYa]

thanks for your solution,

but I have done this with your instructions an i have also found the file: /boot/overlays/mcp2515-can0-overlay.dtb and there is still the message: Cannot find the device "can0". Is there anything missing or shoud i do something else?

[bapou]

I just updated the system and it works! Thank you very much.

[geesamba]

I've got a Pi Model B running 3.12.28+ with the mcp251x modules from here: http://www.cowfishstudios.com/blog/canned-pi-part1 using the PICAN from here: http://skpang.co.uk/catalog/pican-canbu ... -1196.html. I have two wires (high going to pin 6 and low going to 14) just like the cowfish tutorial going into the PICAN.

I'm trying to listen to CAN bus messages via the obd2 port on my 2011 Audi Q5. I have can0 up and I've tried all the bitrates, but I see no messages with candump/cansniffer. The stats on the can0 interface don't even budge from 0.

Is there a technical reason that those messages don't show up on that port? I own a VAG-COM wireless unit, so I know the port works and can "see" things and pull codes.

Any ideas from a VW/Audi user?

Thanks in advance.

[edje4ever]

I just updated the system and it works! Thank you very much.

Hi,
did you get it to work with the B+ model?

[bapou]

I used the RPI 2 B model but can try the B+ tonight

[edje4ever]

I used the RPI 2 B model but can try the B+ tonight

I am using the B+ and I'm having bit timing undefined and unable to set baudrate. However, I did get some output in loopback mode. Do you have any idea why listen-only mode is not working? If you do can you elaborate the steps that you took. Thanks

[geesamba]

I've got a Pi Model B running 3.12.28+ with the mcp251x modules from here: http://www.cowfishstudios.com/blog/canned-pi-part1 using the PICAN from here: http://skpang.co.uk/catalog/pican-canbu ... -1196.html. I have two wires (high going to pin 6 and low going to 14) just like the cowfish tutorial going into the PICAN.

I'm trying to listen to CAN bus messages via the obd2 port on my 2011 Audi Q5. I have can0 up and I've tried all the bitrates, but I see no messages with candump/cansniffer. The stats on the can0 interface don't even budge from 0.

Is there a technical reason that those messages don't show up on that port? I own a VAG-COM wireless unit, so I know the port works and can "see" things and pull codes.

Any ideas from a VW/Audi user?

Thanks in advance.

Ok, so if I use the "loopback" mode when modprobing the mcp251x, I can cansend and candump back and forth over can0 in two ssh sessions. That should indicate the PICAN board is working, correct? So then it must be wiring, right?

Also, to clarify: If I'm sitting in my car with the key in the ignition in switched "on" mode but not running, I should see messages on the CAN bus, correct?

Thanks

[msperl]

Ok, so if I use the "loopback" mode when modprobing the mcp251x, I can cansend and candump back and forth over can0 in two ssh sessions. That should indicate the PICAN board is working, correct? So then it must be wiring, right?

this indicates that the chip is correctly detected (assuming you use the stock mcp251x driver.

This does not necessarily mean that the clock speed that you have configured (via /sbin/ip) is the correct one for the car.
there are a few typical choices for the can speed: 125kHz, 250kHz, 500kHz and 1000kHz. You have to figure out which one it is for your car.

Also you need to make sure that polarity is "correct"!
If you have got a Voltmeter you can check the voltage vs. ground of each one of those.
CanHigh may be between 2-5V and should vary in that range.
CanLow is below CanHigh and typicaly will vary in the range of 0-2.5V.

If you use PiCan then you can also check on Resistor R7 (on the side of the 8 pin chip - pin 4 actually) and see if it stays at constant 5V or if the voltage level varies (which would indicate traffic is detected) - if have reverse polarity the pin should stay constant 5V.

If you see it is varying then the only thing left is figuring out the right baud-rate to configure and then the counters for the can0 interface should start showing packets!

Note that you have to solder 2 bridges in the correct positions (SJ1, SJ2, SJ3) if you want to use the 9-pin connector (I do not know how well the documentation is in this respect, as I am just inferring this from the diagrams/photos of the webpage) - no soldering is needed when using the screw terminal!

Martin

[skpang]

I'm trying to listen to CAN bus messages via the obd2 port on my 2011 Audi Q5. I have can0 up and I've tried all the bitrates, but I see no messages with candump/cansniffer. The stats on the can0 interface don't even budge from 0.

Some OBDII port are isolated from your internal CAN network via a gateway. That is why you might not see any messages.

Set the buadrate to 500k and try do a request like coolant temperature.

./cansend can0 7DF#0201050000000000

You should see a response.

SK Pang

[geesamba]

this indicates that the chip is correctly detected (assuming you use the stock mcp251x driver.

Excellent. That's what I thought.

100kHz,125kHz, 250kHz, 500kHz and 1000kHz. You have to figure out which one it is for your car.

According to this: http://www.volkspage.net/technik/ssp/ssp/SSP_238.pdf, it's either 100kHz or 500kHz depending on which bus I want. But all signs point to 500kHz for my Audi.

Also you need to make sure that polarity is "correct"!
If you have got a Voltmeter you can check the voltage vs. ground of each one of those.
CanHigh may be between 2-5V and should vary in that range.
CanLow is below CanHigh and typicaly will vary in the range of 0-2.5V.

If you use PiCan then you can also check on Resistor R7 (on the side of the 8 pin chip - pin 4 actually) and see if it stays at constant 5V or if the voltage level varies (which would indicate traffic is detected) - if have reverse polarity the pin should stay constant 5V.

Thank you! This will be very helpful, indeed.

Note that you have to solder 2 bridges in the correct positions (SJ1, SJ2, SJ3) if you want to use the 9-pin connector (I do not know how well the documentation is in this respect, as I am just inferring this from the diagrams/photos of the webpage) - no soldering is needed when using the screw terminal!

I did see that and did solder the "left two" bridges, but my soldering must have been a bit off because the driver wouldn't load. So, I undid those solder joints with some wick and set out to make my custom cable to go into the screw posts. This is probably where I'm going wrong, so I'm going to make my cable again.

Thank you for the wealth of info, Martin.

[geesamba]

Some OBDII port are isolated from your internal CAN network via a gateway. That is why you might not see any messages.

Set the buadrate to 500k and try do a request like coolant temperature.

./cansend can0 7DF#0201050000000000

You should see a response.

SK Pang

Now *that* is interesting information. Thank you. Once I redo my cable, I'll give that a try. If this all works and that is the case, then I've got my work cut out for me. I'm up to the challenge, though. Thank you for making the PICAN and lending a hand!

[dave_uk]

Hi Martin,

How do I get the latest firmware with the driver for the mpc25x?

I've tried sudo apt-get update and sudo apt-get upgrade but still no /boot/overlays/mcp2515-can0-overlay.dtb file.

Thanks

Dave_uk

[msperl]

Code: Select all

sudo rpi-update

is your friend...

[rudwna]

Hi,

I've tried to connect RPi and PIC MCU with MCP2515 and MCP2551 as CAN controller and transceiver at each node. One RPi and two PICs on the bus with 120ohm terminating resistor at each end. On RPi I use mcp251x on 3.6.11+ kernel with bit timing parameters set to match those on the PIC:

Code: Select all

bitrate 50000 sample-point 0.750
tq 1000 prop-seg 7 phase-seg1 7 phase-seg2 5 sjw 1

The bus is working occasionally, while on the others it cannot send or receive message. On the RPi candump will just report burst of errors after I use cansend to send a message which look like this:

Code: Select all

 (1426007683.155574)  can0  20000004   [8]  00 20 00 00 00 00 00 00   ERRORFRAME
        controller-problem{tx-error-passive}
 (1426007683.163391)  can0  20000040   [8]  00 00 00 00 00 00 00 00   ERRORFRAME
        bus-off
 (1426007683.192238)  can0  20000004   [8]  00 08 00 00 00 00 00 00   ERRORFRAME
        controller-problem{tx-error-warning}
 (1426007683.200161)  can0  20000040   [8]  00 00 00 00 00 00 00 00   ERRORFRAME
        bus-off
 (1426007683.229020)  can0  20000004   [8]  00 08 00 00 00 00 00 00   ERRORFRAME
        controller-problem{tx-error-warning}
 (1426007683.236952)  can0  20000040   [8]  00 00 00 00 00 00 00 00   ERRORFRAME
        bus-off
 (1426007683.265803)  can0  20000004   [8]  00 08 00 00 00 00 00 00   ERRORFRAME
        controller-problem{tx-error-warning}
 (1426007683.273730)  can0  20000040   [8]  00 00 00 00 00 00 00 00   ERRORFRAME
        bus-off

On the PIC after sending message the TXEP, TXWAR and EWARN flags of MCP2515 are set.
This cause alot of headache for me because I cannot identify the cause of the problem.
Why it sometimes work, while the others doesn't? I don't know if it's the problem in physical layer or not.

Have anyone experiences this before?

Any help would be much appreciated.
Thanks.

-rudwna

[msperl]

Are you sure you want to configure a baud-rate of 50k not 500k?

I wonder because such errors you would get when you have a speed mismatch that result in bit stuff errors/missing acknowledge...

Just checking if it is not a typo.

[rudwna]

Are you sure you want to configure a baud-rate of 50k not 500k?

I wonder because such errors you would get when you have a speed mismatch that result in bit stuff errors/missing acknowledge...

Just checking if it is not a typo.

Yes, at first I try configuring it at higher speed, same errors. So I try to lower the speed to see if it's help but it's not.
And since I don't have an oscilloscope it's hard to know the activity on the bus for troubleshooting.

-Rud

[msperl]

The only thing I can imagine is that you have a mismatch in bitrates.

Do you have the same oscillator on the pic+mcp as you have on the rpi?
If so and you use the 3.12 kernel, then I believe you get the cnf registers printed out to dmesg when configuring the bitrates of ithe interface.

Try to use the identical settings that are reported on the rpi on the mcp+pic systems and check if you get the same result or if the communication works...

Otherwise the only thing that would help is an oscilloscope to investigate.
Or you connect a can transceiver to a pin on the rpi and sample that pin to estimate the bit rates on the bus to see what is expected.

[rudwna]

The oscillators are the same and the CNF registers all have the same values :/

Or you connect a can transceiver to a pin on the rpi and sample that pin to estimate the bit rates on the bus to see what is expected.

Could you please explain this in more details?