I tried to do as indicated in this instruction, but it is outdated and does not produce results on new linux kernels. What I have to do to make the can interface work?
Board: custom board am3359 (almost like beaglebone black)
Target: linux kernel 4.14 , debian 9.9
Target: linux kernel 5.6.4 , debian 10 - same result
Problem: Can-bus working just listen-only-mode
listen-only mode is ok, messages comes:
?
1
2
3
4
5
6
7
|
sudo ifconfig can0 down
sudo ip link ``set can0 ``type can bitrate 125000 listen-only on
sudo ifconfig can0 up
candump -cae can0,0:0,``#FFFFFFFF```<br>```can0 1FE4F1DC [8] 01 64 00 00 00 00 00 00 ``'.d......'```<br>```can0 1FE4F1DC [8] 01 64 00 00 00 00 00 00 ``'.d......'```<br>```can0 1FE4F1DC [8] 01 64 00 00 00 00 00 00 ``'.d......'
|
normal mode bus crashes:
?
I have the impression that your network is set up for J1939 or CANOpen (CAN 2.0B)
when you send a message to a short address (CAN 2.0A) it doesn’t get acknowledged, and this might crash your bus, as the BB will try to send it till the message is acknowledged…
Try to send a message to a 29bit address, or add a second can interface that will acknowledge your messages. (CAN1 on the BB).
I’m a bit stuck on moving over to J1939, as that requires at least kernel 5.4, which results in boot issues due the overlay approach as applied in the Beaglebone OS
You can stop this boot failure, but then I failed to have my network coming up, which was another issue. (I had to work through the debug port)
If you have some advancements in that domain? I am bit time constraint to solve it in the near future.
I hope the next release will have the latest kernel.
Prepare to learn a lot about working with micro controllers and OS environments when working in the CAN domain.
Regards,
Gwen
The issue with 5.4 should now have been resolved… If you have free time, please re-test and let me know.
Regards,
For the record, you do not have to wait for kernel 5.4 to do J1939. I wrote software using kernel 3.8.x that read a hybrid NIMEA 2000 protocol, which uses the same high level protocol as J1939. All you have to do is understand J1939, and bit wrangle . . .
Oh forgot to mention. You’d need to use socketCAN. Perhaps this guy will give you some ideas. https://fabiobaltieri.com/2013/07/23/hacking-into-a-vehicle-can-bus-toyothack-and-socketcan/
Guys, thanks for the answers!
Unfortunately, I can’t use can1, it is have no output on my Board.
It is strange that after a bus crash, ifconfig shows the number of packets transmit 0 and received 3.
If the tire falls after only three attempts to send, it is not normal and does not look like a system for cars that is designed to be reliable.
`
debian@bone:~$ cansend can0 1F334455#1122334455667788
[ 273.654439] can: raw protocol (rev 20170425)
[ 273.670296] c_can_platform 481cc000.can can0: bus-off
debian@bone:~$ sudo ifconfig
can0: flags=129<UP,NOARP> mtu 16
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 10 (UNSPEC)
RX packets 3 bytes 24 (24.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 47
…
`
This is more complicated than I thought.
Without any code, or steps you’ve taken. No one can help, or say what’s going on. I will say this however. I wrote in a relatively short period of time( with help! From multiple sources). Software that could communicate over CANBUS that was able to decode information from a “TRACE” inverter(XanBus) in real-time. This ran for weeks at a time, displaying the information in a web interface. Proven 100% accurate.
I would not say that using the CANBUS hardware interface on the beaglebone is 100% rock solid, but it had been very reliable in my case. Once I knew what I was doing. The only real problem we had was we were completely off-grid, powered by solar. So when we switched from solar power, to the genset. The quick power blip would sometimes put the beaglebone in a wonkey state. However, creating, and using canbus traffic logs. I was able to keep a working beaglebone powered via a laptop for months.
Probably the first place to look is at the hardware you’re using. But I’d double check everything.
By the way “1F334455#1122334455667788” doesn’t look like a valid J1939 packet. But I barely know that particular protocol.