Linux CAN on Vybrid VF50

KD001 · February 23, 2018, 4:49am

I’ve made the preparations to engage CAN1 on my colibri vf 50 board running on viola 1.1. The dtsi is changed as per the suggestions given inhere. The board comes up with the following message in dmesg.

[   14.627493] CAN device driver interface
[   14.872628] vf610-pinctrl 40048000.iomuxc: pin VF610_PAD_PTB16 already requested by 40048000.iomuxc; cannot claim for 400d4000.flexcan
[   14.903666] vf610-pinctrl 40048000.iomuxc: pin-38 (400d4000.flexcan) status -22
[   14.930582] vf610-pinctrl 40048000.iomuxc: could not request pin 38 (VF610_PAD_PTB16) from group can1grp  on device 40048000.iomuxc
[   14.963561] flexcan 400d4000.flexcan: Error applying setting, reverse things back
[   16.471036] 400d4000.flexcan supply xceiver not found, using dummy regulator
[   16.756042] flexcan 400d4000.flexcan: device registered (reg_base=884f0000, irq=45)

While the hardware works with the CAN sniffer, when connected to viola, the error reported is always network down. Can someone suggest something please.

link text

  1 diff --git a/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi b/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
  2 index dc70304..37f2d64 100644
  3 --- a/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
  4 +++ b/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
  5 @@ -95,6 +95,10 @@
  6         status = "okay";
  7  };
  8 
  9 +&can1 {
 10 +       status = "okay";
 11 +};
 12 +
 13  &dspi1 {
 14         status = "okay";
 15 
 16 @@ -200,6 +204,8 @@
 17  };
 18 
 19  &iomuxc {
 20 +       pinctrl-0 = <&pinctrl_hog_1>;
 21 +
 22         vf610-colibri {
 23                 pinctrl_can_int: can_int {
 24                         fsl,pins = <

marcel.tx · February 23, 2018, 6:43am

What exact hardware and software versions of thing are you talking about?

marcel.tx · February 23, 2018, 6:45am

Most likely you missed the part about pin mixing. Please post your exact device tree changes if you expect us to be able to help you.

KD001 · March 2, 2018, 2:02pm

The update of the patch above that includes addition of line 20…21 of iomuxc made the pin errors go away. That clears the first hurdle. Now the Viola board does not report any problems while bootup. additionally i have observed no message coming in or going out of the CAN1_TX or CAN1_RX pins.

root@colibri-vf:~# dmesg | grep can
[   15.031665] 400d4000.flexcan supply xceiver not found, using dummy regulator
[   15.197365] flexcan 400d4000.flexcan: device registered (reg_base=88508000, irq=45)
[  178.778307] can: controller area network core (rev 20120528 abi 9)
[  178.840624] can: raw protocol (rev 20120528)

KD001 · March 5, 2018, 4:41pm

A check again in the CAN Linux page showed this change in the vf-colibri-eval-v3.dtsi

 &i2c0 {
-       status = "okay";
+       status = "disabled";

And so after changing this there is still no progress in the CAN Tx or Rx

jaski.tx · March 6, 2018, 8:29am

which bsp version are you using? can you send the dmesg log in a file? Thanks!

KD001 · March 6, 2018, 3:41pm

link text

Is there any other way to find the bsp version for my setup?

jaski.tx · March 7, 2018, 10:29am

Thanks for the dmesg log. You can go to uboot and type print ver.
Additionally you should see the information in the console when you startup the module.

jaski.tx · March 8, 2018, 2:22pm

Hi Sohal,

Can you type ip l in the console window and see if there is can0 and can1 showing up?
I have checked again the device tree files, we need to update our can article. These are the changes you have to apply to get can0 and can 1 working.

diff --git a/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi b/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
index dc70304..102fbc9 100644
--- a/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
+++ b/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
@@ -88,6 +88,15 @@
        status  = "okay";
 };
 
+&can0 {
+       status = "okay";
+};
+
+&can1 {
+       status = "okay";
+};
+
+
 &dcu0 {
        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_dcu0_1>;
@@ -133,7 +142,7 @@
 };
 
 &i2c0 {
-       status = "okay";
+       status = "disabled";
 
        /* Atmel maxtouch controller */
        atmel_mxt_ts: atmel_mxt_ts@4a {
diff --git a/arch/arm/boot/dts/vf-colibri.dtsi b/arch/arm/boot/dts/vf-colibri.dtsi
index 7d11341..00d1d2e 100644
--- a/arch/arm/boot/dts/vf-colibri.dtsi
+++ b/arch/arm/boot/dts/vf-colibri.dtsi
@@ -276,8 +276,8 @@
                                VF610_PAD_PTA31__GPIO_21        0x22ed
                                VF610_PAD_PTB6__GPIO_28         0x22ed
                                VF610_PAD_PTB7__GPIO_29         0x22ed
-                               VF610_PAD_PTB16__GPIO_38        0x22ed
-                               VF610_PAD_PTB17__GPIO_39        0x22ed
+                               /* VF610_PAD_PTB16__GPIO_38     0x22ed */
+                               /* VF610_PAD_PTB17__GPIO_39     0x22ed */
                                VF610_PAD_PTB18__GPIO_40        0x22ed
                                VF610_PAD_PTB21__GPIO_43        0x22ed
                                VF610_PAD_PTB22__GPIO_44        0x22ed

KD001 · March 9, 2018, 9:39am

I’ll update you with my findings after applying the above patch. Thanks for your help.

jaski.tx · March 9, 2018, 9:44am

You are welcome.

KD001 · March 9, 2018, 12:01pm

I’m back with no good news. The changes in the dtsi files resulted in no difference in activity of CAN1_RX or CAN1_TX. The result of ip l is: `

root@kolibriWhite:~# ip l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,DYNAMIC,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:14:2d:49:c3:9a brd ff:ff:ff:ff:ff:ff
3: can0: <NOARP,ECHO> mtu 16 qdisc noop state DOWN mode DEFAULT group default qlen 10
    link/can
4: can1: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP mode DEFAULT group default qlen 10
    link/can
5: usb0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:14:2d:ff:ff:ff brd ff:ff:ff:ff:ff:ff
6: wlan0: <BROADCAST,MULTICAST,DYNAMIC,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DORMANT group default qlen 1000
    link/ether 00:36:76:02:2d:82 brd ff:ff:ff:ff:ff:ff

And the final dtsi changes are

diff --git a/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi b/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
index dc70304..01e440b 100644
--- a/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
+++ b/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
@@ -133,7 +133,7 @@
 };
 
 &i2c0 {
-       status = "okay";
+       status = "disabled";
 
        /* Atmel maxtouch controller */
        atmel_mxt_ts: atmel_mxt_ts@4a {
@@ -199,6 +199,14 @@
        vbus-supply = <&reg_usbh_vbus>;
 };
 
+&can0 {
+       status = "okay";
+};
+
+&can1 {
+       status = "okay";
+};
+
 &iomuxc {
        vf610-colibri {
                pinctrl_can_int: can_int {
diff --git a/arch/arm/boot/dts/vf-colibri.dtsi b/arch/arm/boot/dts/vf-colibri.dtsi
index 7d11341..fbc5421 100644
--- a/arch/arm/boot/dts/vf-colibri.dtsi
+++ b/arch/arm/boot/dts/vf-colibri.dtsi
@@ -276,8 +276,8 @@
                                VF610_PAD_PTA31__GPIO_21        0x22ed
                                VF610_PAD_PTB6__GPIO_28         0x22ed
                                VF610_PAD_PTB7__GPIO_29         0x22ed
-                               VF610_PAD_PTB16__GPIO_38        0x22ed
-                               VF610_PAD_PTB17__GPIO_39        0x22ed
+                       /*      VF610_PAD_PTB16__GPIO_38        0x22ed */
+                       /*      VF610_PAD_PTB17__GPIO_39        0x22ed */
                                VF610_PAD_PTB18__GPIO_40        0x22ed
                                VF610_PAD_PTB21__GPIO_43        0x22ed
                                VF610_PAD_PTB22__GPIO_44        0x22ed

And the ifconfig on CAN1 shows that I have Rx packets, and Tx packets dropped, as follows:

 root@kolibriWhite:~# ifconfig can1
    can1      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:2 errors:0 dropped:0 overruns:0 frame:0
              TX packets:0 errors:0 dropped:1 overruns:0 carrier:1
              collisions:0 txqueuelen:10
              RX bytes:16 (16.0 B)  TX bytes:0 (0.0 B)
              Interrupt:45

KD001 · March 9, 2018, 12:16pm

I had suspicion about the flexcan driver failing. Thus I enabled the loopback as shown. It did work.

root@kolibriWhite:~# ip link set can1 down
root@kolibriWhite:~# ip link set can1 type can bitrate 125000 loopback on
root@kolibriWhite:~# ip link set can1 up
root@kolibriWhite:~# ip -s -d link show can1
4: can1: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP mode DEFAULT group default qlen 10
    link/can  promiscuity 0
    can <LOOPBACK> state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
          bitrate 125000 sample-point 0.875
          tq 500 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1
          flexcan: tseg1 4..16 tseg2 2..8 sjw 1..4 brp 1..256 brp-inc 1
          clock 66000000
          re-started bus-errors arbit-lost error-warn error-pass bus-off
          0          0          0          0          1          1         numtxqueues 1
    RX: bytes  packets  errors  dropped overrun mcast
    16         2        0       0       0       0
    TX: bytes  packets  errors  dropped carrier collsns
    0          0        0       1       0       0
root@kolibriWhite:~# candump can1
interface = can1, family = 29, type = 3, proto = 1
<0x001> [1] f4
<0x001> [1] f4
<0x001> [1] f4
<0x1ff> [3] 01 02 03
<0x008> [3] 01 02 03

While sending these test data from another console

root@kolibriWhite:~# cansend can1 500#1e.0.10
interface = can1, family = 29, type = 3, proto = 1
root@kolibriWhite:~# cansend can1 500#1e.0.10
interface = can1, family = 29, type = 3, proto = 1
root@kolibriWhite:~# cansend can1 500#1e.0.10
interface = can1, family = 29, type = 3, proto = 1
root@kolibriWhite:~# cansend can1 -i 0x1ff 0x1 0x2 0x3
interface = can1, family = 29, type = 3, proto = 1
root@kolibriWhite:~# cansend can1 -i 0x8 0x1 0x2 0x3
interface = can1, family = 29, type = 3, proto = 1
root@kolibriWhite:~#

KD001 · March 9, 2018, 12:21pm

I also looked around and found this elaborate. My output about the same pins are similar to the article.

root@kolibriWhite:~# cat /sys/kernel/debug/pinctrl/pinctrl-handles | grep PTB16
    type: CONFIGS_PIN controller 40048000.iomuxc pin VF610_PAD_PTB16 (38)config 000031f1
root@kolibriWhite:~# cat /sys/kernel/debug/pinctrl/pinctrl-handles | grep PTB17
    type: CONFIGS_PIN controller 40048000.iomuxc pin VF610_PAD_PTB17 (39)config 000031f2

The oscilloscope trace in BLUE is the CAN1_RX pin capture on the Viola Board X9 connector.

jaski.tx · March 9, 2018, 1:43pm

The output about the same pins in my case is the same, but I have no packages lost, when i send packages over loopback.

jaski.tx · March 9, 2018, 2:10pm

Can you post the picture again? it is not visible.

KD001 · March 9, 2018, 6:05pm

When I tested the loopback, there were no lost packages. But when I sent it through another CAN device, it reported lost packages.

KD001 · March 9, 2018, 6:06pm

See the attached file. I hope this is a better picture.
You might have to download this picture. It’s better on a screen than on webpage.

KD001 · March 12, 2018, 10:42am

I would want to check if the ALT1 function is correctly set for the PTB16/PTB17 for CAN1 functions. How do i verify that the register settings of (Pin Mux) 0x4004_8098h are set to the right setting for the ALT mode?

jaski.tx · March 12, 2018, 4:00pm

you can check it with devmem2 0x40048098