CAN controller

[chintan09]

Thanks for detailed reply. I hooked up a oscilloscope to the interrupt pin, GPIO 25 on RPI2. And it looks like the interrupt is not being cleared (its stuck at low once I send a cansend command). So my current theory is that somehow GPIO's are not being set correctly.

With mounting debugfs (via mount -t debugfs none /sys/kernel/debug), I could only see two GPIO's being set for LED's. Shouldn't overlay's (mcp2515-can0-overlay and spi-bcm2835-overlay) set the GPIO correctly. Any pointers would be helpful.

For the build, I'm using a custom kernel built via buildroot as opposed to raspbian. Thanks again for taking time in looking at this.

[msperl]

That is why I have said: use the latest foundation provided kernel 3.18! There it works!

[chintan09]

Actually I built again with latest version of rpi-3.18.y kernel and still the same results. The GPIO's seemed to be set correctly.

File - pins after mounting debugfs.

pin 25 (gpio25) function gpio_in in lo; irq 505 (edge-falling)

I have connected PICAN to a ECU Simulator, for which I'm pretty sure I can at-least get the response for (cansend can0 7DF#0201050000000000). Another weird things is that same setup worked really well a week back and then suddenly (after some cleanup un-related) things have stopped working.

[msperl]

If it worked before, then revert back to that (if possible) and then bisect until you get back to when it stopped working.

Again: I would confirm that it still works with the foundation kernel and their device-tree + overlays first and only when it is confirmed to be working move to your personal setup and figure out why it does not work there.
But there you are left alone, as only you know your setup.

But one note: You have gpio25 on interrupt 505 - this seems strange. On a foundation kernel it is (in my case on a RPI2) irq-473 (which is consistent with what other people are posting when they share /proc/interrupts) and with an upstream kernel on RPI B+: irq-105.

So I wonder why you have an offset of exactly 32 in your interrupt table - as if you were using GPIO 57(=25+32) and not 25...

If you run your own device-tree check the settings and compare them to the one the foundation provides...

[chintan09]

Interesting to know about differences in IRQ, don't know where this differences come from.
One question, when you say stock kernel, what image you exactly mean. I thought using rpi-3.18.y kernel is a stock image. If not, could you please point to a working image in your opinion and I can directly use them and give a try.

And No, I am not using my own overlays. This is the config file setting,

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

Finally this is my complete IRQ setup, starting from 480.

# cat pins
registered pins: 54
pin 0 (gpio0) function gpio_in in hi; irq 480 (none)
pin 1 (gpio1) function gpio_in in hi; irq 481 (none)
pin 2 (gpio2) function gpio_in in hi; irq 482 (none)
pin 3 (gpio3) function gpio_in in hi; irq 483 (none)
pin 4 (gpio4) function gpio_in in hi; irq 484 (none)
pin 5 (gpio5) function gpio_in in hi; irq 485 (none)
pin 6 (gpio6) function gpio_in in hi; irq 486 (none)
pin 7 (gpio7) function alt0 in hi; irq 487 (none)
pin 8 (gpio8) function alt0 in hi; irq 488 (none)
pin 9 (gpio9) function alt0 in lo; irq 489 (none)
pin 10 (gpio10) function alt0 in lo; irq 490 (none)
pin 11 (gpio11) function alt0 in lo; irq 491 (none)
pin 12 (gpio12) function gpio_in in lo; irq 492 (none)
pin 13 (gpio13) function gpio_in in lo; irq 493 (none)
pin 14 (gpio14) function alt0 in hi; irq 494 (none)
pin 15 (gpio15) function alt0 in hi; irq 495 (none)
pin 16 (gpio16) function gpio_in in lo; irq 496 (none)
pin 17 (gpio17) function gpio_in in lo; irq 497 (none)
pin 18 (gpio18) function gpio_in in lo; irq 498 (none)
pin 19 (gpio19) function gpio_in in lo; irq 499 (none)
pin 20 (gpio20) function gpio_in in lo; irq 500 (none)
pin 21 (gpio21) function gpio_in in lo; irq 501 (none)
pin 22 (gpio22) function gpio_in in lo; irq 502 (none)
pin 23 (gpio23) function gpio_in in hi; irq 503 (none)
pin 24 (gpio24) function gpio_in in hi; irq 504 (none)
pin 25 (gpio25) function gpio_in in lo; irq 505 (edge-falling)
pin 26 (gpio26) function gpio_in in lo; irq 506 (none)
pin 27 (gpio27) function gpio_in in lo; irq 507 (none)
pin 28 (gpio28) function gpio_in in hi; irq 508 (none)
pin 29 (gpio29) function gpio_in in hi; irq 509 (none)
pin 30 (gpio30) function gpio_in in lo; irq 510 (none)

[msperl]

Interesting to know about differences in IRQ, don't know where this differences come from.
One question, when you say stock kernel, what image you exactly mean. I thought using rpi-3.18.y kernel is a stock image. If not, could you please point to a working image in your opinion and I can directly use them and give a try.

Foundation kernels are the ones that come with rpi-update - i would test with those as these are known to work with the device tree overlays.

Then you can also have 4.0 "upstream" kernels (but you have to use uboot for second stage boot loader and write your own device-tree - no overlays there and no support for the rpi2 either).

[pier1999]

Hello, I had a setup working until I enabled the devicetree on kernel 3.18.11+ and did the following configuration of overlay parameters:

Code: Select all

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

Note the 20 MHz oscillator which is the freq of my can device.
The problem is that when I show the status of can interface it shows a clock of 8000000 which is the value of the default value and which means that ‘oscillator=20000000’ parameter isn’t picked up.
The result is that I always get these errors:

Code: Select all

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

and never got

Code: Select all

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

which is the indication that spi has configured the can device.
Has anyone been able to configure the CAN device with oscillator different than 16MHz?

[msperl]

Note the 20 MHz oscillator which is the freq of my can device.
The problem is that when I show the status of can interface it shows a clock of 8000000 which is the value of the default value and which means that ‘oscillator=20000000’ parameter isn’t picked up.

the status (via

Code: Select all

ip -d -s link show can0

) always only shows HALF the oscillatior value - this is known.
So for you it should be 10000000.

Why it is not doing the right thing - I will need to try to replicate it... (it was working before!)

The result is that I always get these errors:

Code: Select all

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

these are actually warnings that you have not set up the bitrate of the interface yet - you need to run

Code: Select all

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

and those messages stop.

and never got

Code: Select all

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

This does no longer show up with the newer kernels - the "bit-timing not yet defined" now indicates that the device has been identified correctly and the device is ready to configure/use.
Otherwise you would not be able to run the ip command either!

[pier1999]

Thanks for the reply.
When I bring the interface up, messages about the missing baudrate disappear and the interface status is ERROR-ACTIVE (which I learnt from the previous setup is the right status) .
As soon as I try to send a message or there is a message waiting to be read, I get 2 error frames and the status of the interface turns to ERROR-PASSIVE. The clock value I read from the interface status is 8000000 and not the expected 10000000 for a 20Mhz oscillator.
Regards, Pier

[pier1999]

Thanks for the reply.
When I bring the interface up, messages about the missing baudrate disappear and the interface status is ERROR-ACTIVE (which I learnt from the previous setup is the right status) .
As soon as I try to send a message or there is a message waiting to be read, I get 2 error frames and the status of the interface turns to ERROR-PASSIVE. The clock value I read from the interface status is 8000000 and not the expected 10000000 for a 20Mhz oscillator.
Regards, Pier

One more thing, when I run

Code: Select all

vcdbg log msg

I get this output

Code: Select all

005069.580: dtparam: i2c_arm=on
005071.646: dtparam: spi=on
005079.598: Loaded overlay 'spi-bcm2835-overlay'
005087.423: Loaded overlay 'mcp2515-can0-overlay'
005103.762: dtparam: oscillator=20000000
005105.854: dtparam: interrupt=25

[msperl]

I understand - there seems to be an error with the device-tree-overlay that does set the clock in the "wrong" location...
This will need a patch/update of the firmware (when it comes out) - working on that...

Essentially the following:

Code: Select all

oscillator = <&can0_osc>,"oscillator-frequency";

needs to be:

Code: Select all

oscillator = <&can0_osc>,"clock-frequency";

inside the device-overlay.

Martin

[pier1999]

Thank you Martin, do you think the fix will take days or weeks to be in the firmware update? Just to know so that if it take long I'll revert to the old method on the last working kernel.

[msperl]

Totally depends on popcornmix to run the next build and my time to get the patch in place first (but that should be in the next 2 hours I guess)

[msperl]

created pull request: https://github.com/raspberrypi/linux/pull/933

it actually already got merged, so with the next build it should become available

@pier1999: if it is really urgent then download this one: https://github.com/msperl/linux-rpi/blo ... b?raw=true
and put it in /boot/overlays and then it should work.

[pier1999]

I tried the fixed overlay and now It works as expected. The interface status shows the right clock value (10000000) and I can send and receive messages.
Thanks a lot Martin for sharing the fixed overlay.
Pier

[nikkotorcita]

Hi msperl,

I have a 5 node CAN network and one node is just broadcasting a stream of frames with a total payload size of 6.5MB. The remaining 4 are just recipients. The bus rate is at 500kbps and I manually tuned the kernel networking parameters pertaining to sockets to adjust the RX buffer size and the packet queue length. I had to do this because I was getting a lot of controller-rx-buffer-overflow errors since the arrival of frames at the CAN interface is faster than the application can read these frames. I ran a couple of transmission tests and I noticed that I still get controller buffer overflow errors but in some peculiar manner that I dont quite understand. The errors are initially high in number during the first transmission of the 6.5MB payload but they significantly drop in number in the succeeding transmissions until no frame errors surface up. A transmission is one instance of the program running and terminates when all the data is sent. I also noticed that the average time in between these error frames is 20 seconds. I tried changing the kernel socket parameters to higher values but this period between the error frames remained at 20 seconds.

I'd like to ask what you think is happening here. Below are the snapshots of my terminal displaying all 5 nodes.

Cheers!

Transmission #1
- netdev_max_backlog=50000
- rmem_max = 32MB
- rmem_default = 32MB
- error frame rate = ~20 sec
https://drive.google.com/open?id=0B0Vap ... authuser=1

Transmission #2
- same parameters as previous transmission
- reduced number of frame errors
- error frame rate = ~20 sec
https://drive.google.com/open?id=0B0Vap ... authuser=1

Transmission #3
- same parameters as previous transmission
- significantly reduced number of frame errors. only 1 this time.
https://drive.google.com/open?id=0B0Vap ... authuser=1

Transmission #4
- same parameters as previous transmission
- no error frames surfaced
https://drive.google.com/open?id=0B0Vap ... authuser=1

[msperl]

500KHz and lots of CAN-messages getting sent back to back over the bus are still happening to trigger delays with the current framework - but even then you can not make 100% sure you receive every message - it is linux (not hard real-time) and the 2 receive buffers on the mcp251x are too few to make certain NOT to loose even a single message because something else is happening on the system.

Those latest improvements that made it into the foundation 4.0 kernel (and might also make it into 3.18 eventually) improve the situation, but you can not work around the limitation of only 2 packet buffers on the mcp251x.

If you need something more reliable, then you either need to go with a different can-controller that has more buffers (only sja1000 comes to my mind, but I have not tested it) or you need to add some microcontroller with some memory in the middle to act as a buffer (but then you need to write your own driver for the kernel).

But as to why it sometimes works better than others is because sometimes more code used to handle the messaging is in the CPU caches, which can save a few us. On top there are right now dependencies on scheduling, so we have multiple independent processes that are involved when communicating with the chip, which introduces latencies - more if there are other processes also consuming CPU.

Hope that is enough insight.

[nikkotorcita]

Hi msperl

That is very much helpful!

Is it possible to compile the kernel with PREEMPT_RT without breaking anything in the Pi in order to reduce latencies that might be causing the CPU to miss reading the limited receive buffer of the MCP2515?

Cheers!

[msperl]

Realtime was enabled earlier, but i am not sure if it still is.
On top Realtime generally gives some guarantees on response, but it is not necessarily in the us range.

but you have tho think of the times it takes to transfer a message on the bus:
between 47us (11-bit ID, 0 byte data) and 158us (29-bit ID and 8 byte of data) for a CAN message on a bus running at 1MHz - these obviously scale with the bus-speed.

See also: http://www.esacademy.com/en/library/cal ... lator.html

The RPI has to handle EVERYTHING within that time-frame if it does not want the message to overflow to the second buffer or get dropped if the 2nd buffer is also full...

That is VERY little time when you know that a single interrupt can take something like 25-30 us to get handled (start to end with a minimal implementation in the middle) - so it is always a race for faster speeds.

That is why it would be nice if the mcp2515 had more receive-buffers (than 2), as this would act as a buffer for latencies delays and allow more time for the RPI to get started without loosing a can message, because it is busy writing something to SD-card or transfer data over the network,...

All this is an issue if you have MANY packets that come in with minimal spacing at higher CAN-bus-speeds.

So either you have to live with that, reduce the BUS speed (125kHz is very reliable) or you have to come up with a different approach - say using SL_CAN (=serial can) and a microprocessor to handle the hard real-time stuff and implement some extra buffers (but that has its own limitations as you need to transfer 2 bytes for each byte received + some more overhead, so the serial line needs to be fast - say 3-4 time the CAN bus speed, as you would fill the buffer as well at some point) - or use an USB solution...

[msperl]

@nikkotorcita: I had a look at the mcp251x driver today while thinking about reducing latencies further and making sure that more packages arrive...

So here the summary: if you wire the RX0BF and RX1BF pins (10 and 11) of the mcp2515 to some GPIOs on the rpi then - with the corresponding patch to the driver you can reduce latencies by about 20us - between 64 and 76us with patch and 83 to 97us for the original) this gives you some safety-margin, but it still leaves some time between interrupt signal and the interrupt handler actually running, which may be in the range of 20-40us alone (that is with upstream and a .

So there would still be some benefit running the driver in callback mode alone to avoid the initial scheduling overhead.
But that would mean this time to develop the improvements and trying to upstream it in small "acceptable" portions, but that is still a big change to the driver, so there will be some resistance to such a change.

But in any case it may not be sufficient to keep up with a sustained transfer of 0 byte CAN packets at 1MBit.

If you are talking about 1MBIt and 8 byte data then it is less of a problem to keep up with that, but every us saved will help and there is unfortunately NO 100% certainty that it will always keep up(especially if you do a lot of activity on USB or write to SD-card)...

[MrBool]

if you wire the RX0BF and RX1BF pins (10 and 11) of the mcp2515 to some GPIOs on the rpi then - with the corresponding patch to the driver you can reduce latencies by about 20us

Where can I find such patch?

[msperl]

Only on my rpi for now...

Here my quick patch:

Code: Select all

diff --git a/drivers/net/can/spi/mcp251x.c b/drivers/net/can/spi/mcp251x.c
index bf63fee..78014a9 100644
--- a/drivers/net/can/spi/mcp251x.c
+++ b/drivers/net/can/spi/mcp251x.c
@@ -70,6 +70,7 @@
 #include <linux/module.h>
 #include <linux/netdevice.h>
 #include <linux/of.h>
+#include <linux/of_gpio.h>
 #include <linux/of_device.h>
 #include <linux/platform_device.h>
 #include <linux/slab.h>
@@ -198,6 +199,13 @@
 #define RXMSIDL(n) ((n) * 4 + 0x21)
 #define RXMEID8(n) ((n) * 4 + 0x22)
 #define RXMEID0(n) ((n) * 4 + 0x23)
+#define BFPCTRL	      0x0c
+#  define BFPCTRL_B0BFM	0x01
+#  define BFPCTRL_B1BFM	0x02
+#  define BFPCTRL_B0BFE	0x04
+#  define BFPCTRL_B1BFE	0x08
+#  define BFPCTRL_B0BFS	0x10
+#  define BFPCTRL_B1BFS	0x20
 
 #define GET_BYTE(val, byte)			\
 	(((val) >> ((byte) * 8)) & 0xff)
@@ -269,6 +277,8 @@ struct mcp251x_priv {
 	struct regulator *power;
 	struct regulator *transceiver;
 	struct clk *clk;
+
+	int gpio_rx[2];
 };
 
 #define MCP251X_IS(_model) \
@@ -557,6 +567,20 @@ static int mcp251x_set_normal_mode(struct spi_device *spi)
 {
 	struct mcp251x_priv *priv = spi_get_drvdata(spi);
 	unsigned long timeout;
+#ifdef CONFIG_GPIOLIB
+	u8 data;
+#endif
+
+#ifdef CONFIG_GPIOLIB
+	/* set output PINS for RX0/RX1 with the correct function */
+	data = 0;
+	if (gpio_is_valid(priv->gpio_rx[0]))
+		data |= BFPCTRL_B0BFM | BFPCTRL_B0BFE;
+	if (gpio_is_valid(priv->gpio_rx[1]))
+		data |= BFPCTRL_B1BFM | BFPCTRL_B1BFE;
+	if (data)
+		mcp251x_write_reg(spi, BFPCTRL, data);
+#endif
 
 	/* Enable interrupts */
 	mcp251x_write_reg(spi, CANINTE,
@@ -639,7 +663,7 @@ static int mcp251x_hw_reset(struct spi_device *spi)
 
 	/* Wait for oscillator startup timer after reset */
 	mdelay(MCP251X_OST_DELAY_MS);
-	
+
 	reg = mcp251x_read_reg(spi, CANSTAT);
 	if ((reg & CANCTRL_REQOP_MASK) != CANCTRL_REQOP_CONF)
 		return -ENODEV;
@@ -812,6 +836,26 @@ static irqreturn_t mcp251x_can_ist(int irq, void *dev_id)
 		u8 clear_intf = 0;
 		int can_id = 0, data1 = 0;
 
+#ifdef CONFIG_GPIOLIB
+		/* check the gpios and handle the receive messages
+		 * as quickly as possible
+		 */
+		if (gpio_is_valid(priv->gpio_rx[0]) &&
+		    (gpio_get_value(priv->gpio_rx[0]) == 0)) {
+			mcp251x_hw_rx(spi, 0);
+			if (mcp251x_is_2510(spi))
+				mcp251x_write_bits(spi, CANINTF,
+						   CANINTF_RX0IF, 0x00);
+		}
+		if (gpio_is_valid(priv->gpio_rx[1]) &&
+		    (gpio_get_value(priv->gpio_rx[1]) == 0)) {
+			mcp251x_hw_rx(spi, 0);
+			if (mcp251x_is_2510(spi))
+				mcp251x_write_bits(spi, CANINTF,
+						    CANINTF_RX1IF, 0x00);
+		}
+#endif
+
 		mcp251x_read_2regs(spi, CANINTF, &intf, &eflag);
 
 		/* mask out flags we don't care about */
@@ -1093,6 +1137,16 @@ static int mcp251x_can_probe(struct spi_device *spi)
 		goto out_clk;
 	}
 
+#ifdef CONFIG_GPIOLIB
+	if (spi->dev.of_node) {
+		priv->gpio_rx[0] = of_get_gpio(spi->dev.of_node, 0);
+		priv->gpio_rx[1] = of_get_gpio(spi->dev.of_node, 1);
+	} else {
+		priv->gpio_rx[0] = -ENOENT;
+		priv->gpio_rx[1] = -ENOENT;
+	}
+#endif
+
 	ret = mcp251x_power_enable(priv->power, 1);
 	if (ret)
 		goto out_clk;

and in the device-tree you have to add:

Code: Select all

gpios = <&gpio X 0>, <&gpio Y 0>;

Where X is the GPIO connected to RX0BF (PIN 12) and Y is the GPIO connected to RX1BF (PIN 11).

But for all practical purposes you should be using kernel version 4.0 or later, as only this has one improvement that helps more that that "small" patch here...

[MrBool]

msperl, thank you very much for reply.

But for all practical purposes you should be using kernel version 4.0 or later, as only this has one improvement that helps more that that "small" patch here...

What improvement has kernel version 4.0 or later? Is this patch will be included in kernel 4.0?

I'm designing now my board for compute module and I don't know is it good idea to connect signals RX0BF and RX1BF to GPIOs?

[msperl]

msperl, thank you very much for reply.
What improvement has kernel version 4.0 or later? Is this patch will be included in kernel 4.0?

4.0 contains an improvement that improves speed of spi_sync calls when the spi-bus driver use a newer driver model (which the bcm2835 does).

This has the effect that it does not have to do a "context" switch under some circumstances, which adds delays.

This actually works best with the improvements to spi-bcm2835 (polling for short transfers) that are scheduled for 4.1 - and are merged in the foundation 4.0 kernel, which they will ship eventually.

And: no that patch has not been pushed upstream (yet).

I'm designing now my board for compute module and I don't know is it good idea to connect signals RX0BF and RX1BF to GPIOs?

Well - If you have GPIOs that are unused (and would remain that way) then you may want to add a wire for them to those pins - just add a pullup and prepare to connect it via a 0Ohm resistor.
It does not cost you much (besides putting it in your design) and if the patch goes in then you are ready to make use of it...

As you design your board now one warning (just in case): if you share the SPI bus between the mcp2515 and other devices, then you can NOT expect no packet-loss, as those devices will also block the bus for some time counting against the reaction-time of yours.

Example if you think of adding a TFT also connected via SPI, then the transfers to the TFT are typically 4k in size (maybe longer) and that means that the spi bus is occupied for at least 0.0018 seconds (@20MHz), which is much longer than a single can-message takes on the can bus - the longest can-message at 1MHz takes 0.000158 seconds - so >10 can-messages would arrive while the transfer to the TFT is in progress and only the first 2 messages would be received and the others lost.

So think of the SPI bus as dedicated to the mcp2515 if you ever want to avoid packet-loss...

[Feldspar17]

Martin -

Thank you for all the informative posts you've made on this thread. I had a couple of questions. I'm using a Pi Model B, with a PICAN board, to connect to a vehicular CAN-bus. My problem is that I can set up the software correctly and start candump, and as soon as I plug the cable/wires into the OBDII port, I see valid CAN data on the Pi via candump - but only for a couple of seconds or so, before it stops receiving completely.

1. Do you think this is related to the 2 buffer mcp2515 limitation you've mentioned before?
2. If so, is it possible to update to the 3.18 version of the kernel on a Model B and fix this problem, or would I have to switch to the Pi 2?

Thanks in advance.

Best,
Michael