Can get DCAN0 going but not DCAN1

I’ve been following the examples provided here ( http://www.aero-box.co.uk/beaglebone-black#TOC-CANbus ) and have managed to get both CAN modules to show up, but I can only get CAN0 to transmit and receive. Nothing untoward shows up in dmesg, and I can bring up the devices; its only CAN1 that doesn’t work. Does anyone have any suggestions to figure out what could be wrong?

I’m running Ubuntu 13.04 (07-22), and have the following modifications to my am335x-bone-common.dtsi file:

`

snip
dcan0_pins: pinmux_dcan0_pins {
pinctrl-single,pins = <
0x178 0x12 /* ic2c.sda_dcan0_rx, SLEWCTRL_FAST | INPUT_PULLUP | MODE2 /
0x17C 0x32 /
ic2c_scl.dcan0_rx, SLEWCTRL_FAST | RECV_ENABLE | INPUT_PULLUP | MODE2 */

;
};

dcan1_pins: pinmux_dcan1_pins {
pinctrl-single,pins = <
0x180 0x12 /* uart1_rxd.d_can1_tx, SLEWCTRL_FAST | INPUT_PULLUP | MODE2 /
0x184 0x32 /
uart1_txd.d_can1_rx, SLEWCTRL_FAST | RECV_ENABLE | INPUT_PULLUP | MODE2 */

;
};
*snip

snip

uart2: serial@48022000 {
status = “disabled”;
};

dcan0: d_can@481cc000 {
status = “okay”; // Switch on DCAN0
pinctrl-names = “default”; // Apply default pinmuxing
pinctrl-0 = <&dcan0_pins>;
};

dcan1: d_can@481d0000 {
status = “okay”; // Switch on DCAN1
pinctrl-names = “default”; // Apply default pinmuxing
pinctrl-0 = <&dcan1_pins>;
};
snip

snip

&i2c2 {
status = “disabled”;
pinctrl-names = “default”;
pinctrl-0 = <&i2c2_pins>;
snip

`

And my /proc/net/dev file:

`

Inter-| Receive | Transmit
face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed
lo: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
eth0: 2351960 13013 0 0 0 0 0 0 32410 388 0 0 0 0 0 0
usb0: 474271 9333 0 0 0 0 0 0 4156896 15720 0 0 0 0 0 0
can0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
can1: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

`

And my /sys/kernel/debug/pinctrl/44e10800.pinmux/pins

`

snip
pin 94 (44e10978) 00000012 pinctrl-single
pin 95 (44e1097c) 00000032 pinctrl-single
pin 96 (44e10980) 00000032 pinctrl-single
pin 97 (44e10984) 00000012 pinctrl-single
snip

`

Thanks in advance.

You question did not disappear. When you register your posts are moderated. I had not yet reviewed your initial post and approved it. So, I deleted your second post.

Gerald

Thanks Gerald. Noticed that after I made the second post. :slight_smile:

While I can’t help solve the problem, maybe I can provide some more information to help debug it, as it appears I’m seeing a similar problem.

I am merely trying to get DCAN1 up and running, and have followed numerous tutorials, etc (including the one Scott points out) to get the DCAN1 running, and I can’t get it to send data. I’ve not tried receiving, because if I can’t send then I don’t care if I can’t receive at this point.

The interesting thing I notice is when I do cansend, I get data spewing back and forth on the wire. I’ve tried this with a CANBus controller as well as just tying DCAN1_TX and DCAN1_RX together. If I disconnect one of the Tx/Rx lines, then the spewing stops.

Here is what I do:

reboot

`
canconfig can0 ctrlmode bitrate 125000 triple-sampling on
canconfig can0 start
cansend can0 051#11.22.33.44.55.66.77.88

`

This results in no Tx bytes as reported by ifconfig or ip -details -statistics link show can0. The ip link shows that the can state is ERROR-PASSIVE which from my exhaustive research says that there is an active error, and it will listen, but not transmit. Previous to this, the state as ERROR-ACTIVE (which is supposedly OK).

I’d love to figure out what the problem we’re running into is.

My system details:
Angstrom base image with 3.8.13 kernel image
I’ve also built an image from the Ubuntu directions and tried that with no difference (I’ve not built the whole image as I don’t have a 4GB SD card yet).

Thanks in advance for any help that can be provided,
Drew Hintz

One of the things about CAN is that it is a protocol that requires at least 2 nodes to be present. One node to send data, and at least one node to state that it received a valid message and send back an ACK bit.

When you send your data without anything attached on the other end, that ACK bit doesn’t come back, and you get an error (not sure which one). That will probably be why you are having issues if you don’t tie in RX and TX. Depending on the type of driver, it may retry for some time, waiting for the ACK bit to come back, or it might only try once, but it will eventually give up and give you some kind of bus error. This may be your problem Drew.

My problem is that the data doesn’t even show up on the pins. It just sits active high (probably due to the pull up from the MUX) and never moves. :frowning:

Scott,

Thanks for the insight. I had not known that about CANbus. I am in the process of getting my other nodes set up, so maybe once I get one of those going, things will work better. If so, I will let you know.

Drew

No worries. :slight_smile:

If/when you get it going, can you post your .dtb(i) files here so I can give it a go on my hardware? If I can’t get it going, I might have to RMA.

Cheers,
Scott.

Scott,

once I added a TMS28035 uC with CAN on the other end of the CANbus (and I got all the wiring right) it all seems to be working correctly. The only thing I notice so far is that it seems to lock up the O/S if I have the remote node banging away at 1Mbps. I’m going to look into this further, but for now, here’s my .dtsi file. It’s the result of the howto that you linked to above.

Then after I boot, I run:
`
canconfig can0 ctrlmode bitrate 1000000 triple-sampling on
canconfig can0 start

`

`
/*

Thanks for posting that Drew. Unfortunately it didn’t work for me, so I’m guessing that something is hosed on the board. RMA time. :frowning:

thank you so much for clarifiation m8!
been trying to get my BB Green to communicate CAN for too long now, actually ERROR- passive vs. active led me to right track here!