Hello,
I am using “Waveshare CAN Cape” for sending CAN messages from Beaglebone Black. I communicate with Beaglebone using ethernet by making SSH connection and I have latest Debian OS on BBB.
Sometimes when I restart the Beaglebone it shows an error message saying “Network is down”. Because of this my whole CAN communication stops to work.
I am not sure why there is this inconsistency with BBB. Please let me know if there is any possible solution for this.
Thank you,
Akash G.
Of course the can network goes down when you reboot the system, but you need to be more clear as to what your problem is. Do you have a script that runs on startup that is failing, or what ?
Yes. I do have a script that runs at startup.
Even if I try to run that script manually it shows the same error.
Can you please tell me how does sometimes the CAN network goes down on rebooting the BBB?
Yes. I do have a script that runs at startup.
Even if I try to run that script manually it shows the same error.
Ok, you’re still not being very verbose. Tell us everything you can think of, preferably in order. When does it not work ? when does it work ? Does it ever stop working in the middle of working ? Details . . .
Can you please tell me how does sometimes the CAN network goes down on rebooting the BBB?
No, I can only guess because you’re not giving enough information. But if I had to guess right now I’d say you’re having a script / driver module race condition. But even that does not sound 100% right.
You need to apply some troubleshooting for situation . . .
I have script that runs at startup which initializes the CAN communication on my BBB. Whenever I restart my BBB this script does work most of the times, I would say 7 out of 10.
Once the CAN is up successfully it never stops in middle of working. Then I generally use Candump to fetch all the values from CAN bus.
The only issue is, sometimes on reboot I get the error message saying “Read: Network is Down”. So I am wondering what is the possible issue from BBB side.
Ok, so how do you fix the problem ? manually bring the CANBUS interface up ? If that is te case, then you need to start your script later in the boot process. Using rc.d may do the trick, but in case you’re already using rc.d, then you may need to setup a cron job to 30 seconds after boot, or something. This would need trial and error. In other words this strongly sounds like some kind of “race condition”.
With systemd there is a way to test for prerequisite services, but I do not know systemd well enough to advise you there.
Thank you very much. I will try to implement your suggested ways.
Right now I am actually using service routine that executes the script that initializes the CAN.
At the start of script I have given delay of 20 seconds.
Thank you very much. I will try to implement your suggested ways.
Right now I am actually using service routine that executes the script that initializes the CAN.
At the start of script I have given delay of 20 seconds.
No problem.
SO here is what I am guessing that happens. SocketCAN relies on the Linux networking API’s to work. So, it is my assumption that if networking on your system is not ready at the time you’re attempting to bring the CANBUS interface up. It’ll fail. What I say here is 100% correct, but I’m not positive this is what is happening in your case.
Perhaps you could even write a script to help troubleshoot this problem. But at this moment I’m not sure what would be a good thing to test for. The output of lsmod might not be very helpful.
Is there a way to check if Linux networking API’s are ready or not using some command?
Well, it’s not really the API’s that’s the problem, networking it’s self. You could test the output of ifconfig canX, then parse for “UP” or “DOWN”. Or you can perhaps test the /proc/ pseudo file system somehow to check if the device is up or not. After that, you can continue, or attempt to bring the interface up again.
There may even be an interrupt you can test for . . . I’d have to look into it further, which I’m not going to do right now. Busy day today for me and I’m away from my computer most of the day . . .