I’m trying to get the canbus on the beglebone black working, but I’m having the following issues:
1- I can only receive data when I’m on listen-only mode. If I turn the listen-only mode off, i stop receiving data from the bus
2- I cannot send data. I try it using the cansend utility, and I get the message “write: No buffer space available”. It looks like the buffer is not being flushed to the bus, or something like this. I have already tried with two BBBs and got the same result.
I’m connecting the beagle to the bus with a sn65hvd230 transceiver and kernel 3.8.13.
Now I have set the loopback mode on. I can see the TX pin of the BBB sending bytes with an oscilloscope, but when it’s off I can’t see anything on the TX pin
It looks like you have the pin-mux settings correct so I think we can rule out a problem with the device tree configuration.
How are you controlling the can modules? From the command line using ‘ip link set can0…’, or can-utils (canconfig…)?
The first thing to check would be what state the can controller is going into during the exercise. When you set it to ‘bus on’ mode does it very quickly go into ‘error passive’ (bus off) mode? If this is the case you probably have one of the following problems:
No receiving device: The can bus module relies on their being at least one other device on the network to acknowledge (pull the bus low) any transmitted message - if there is no such device the can bus will very quickly go into error passive mode after trying to tx your first message 127 consecutive times.
Incorrect bit timing: You may have another ‘know good’ device on the network, but you may have used incorrect bit timing and hence made your device incompatible with other devices on the bus. Check the specs of the other devices.
Incorrect physical layer wiring/termination: Make sure all your CAN-H’s are wired together in parallel and that all your CAN-Ls are also, and that their is at least one 120Ohm resistor between these lines.
The fact that you can rx from another device in listen-only mode means you are close to having this working and that the physical layer is probably ok - although double check everything. It may be that there is some kind of auto baud rate detection going on in listen-only mode, so when you manually set your bit timings and go bus on things get broken.
Thank you for your response… but I finally found the problem here… it was a faulty tranceiver. The beaglebone can0 configuration was ok, and I could see that the ACK was being sent by the beagle with the oscilloscope. So I decided to test the transceiver, sending some data from the beagle and hooking the oscilloscope to the bus. I could see the beaglebone TX pin trying to send some data to the transceiver, but that data never made it to the bus, so I replaced the transceiver and everything started to work as expected.
I am designing a custom cape with CAN bus function. The transceiver that I use is SN65HVD251D. The kernel is mainly follow Robert Nelson’s 3.8.13. The kernel config is
I am trying to undertsand where Ubuntu hides the correct .dbto I couldnt find it in the file system I got everything to work except probing the actual ouput with a scope
Here is the TowerTech load
Ubuntu 13.04 arm ttyO0
arm login: ubuntu
Password:
Last login: Sun Sep 15 22:02:12 UTC 2013 on ttyO0
Welcome to Ubuntu 13.04 (GNU/Linux 3.8.13-bone28 armv7l)
Documentation: https://help.ubuntu.com/
ubuntu@arm:~$ dmesg | grep -i can
[ 0.150126] of_get_named_gpio_flags: can’t parse gpios property
[ 1.493411] bone-capemgr bone_capemgr.8: slot #3: ‘TT3201 CAN Cape,01,TowerTech,TT3201-001’
[ 1.589830] bone-capemgr bone_capemgr.8: slot #3: Requesting firmware ‘TT3201-001-01.dtbo’ for board-name ‘TT3201 CAN Cape’,