Hi William,
uname -r returns 3.8.13-bone47 from the revC board that arrived a couple of 
weeks ago.
I'm running with a 2A supply since I as using a WiFi USB module.  At the 
moment I'm hardwired again.
Following the instructions in Derek Malloy's "Exploring Beaglebone" I 
created a user and a group.  Also used visudo to add my user to the sudo 
file so I can run root stuff.
Logged on as the user I've now had the 1Mbps CAN messages running for over 
4 hours.  I can log in with Chrome into Cloud9 and create a terminal which 
automatically logs in as root.  No more lock ups.
If I have more problems I'll start a new thread.  Very strange.
Thanks


On Saturday, April 11, 2015 at 2:46:44 PM UTC-7, William Hermans wrote:

> @John D
>
> Which kernel version are you running on the black ? kernel version 3.14.x 
> is supposed to bring some USB, and ethernet improvements over kernel 
> version 3.8.x. However, I'm not sure what exactly these improvement are. 
> Anyhow, it was a thought while reading your post. I do know that early on 
> with kernel 3.8.x if you tried to hotplug ethernet or USB, you'd get a 
> kernel panic. Symptoms similar to what you're explaining here, You'd try to 
> hotplug, everything would work fine for around a minute, then the board / 
> system would just freeze. 
>
> Another thought that I had was that you may be powering over USB only ? 
> Perhaps you are not getting enough power.
>
> You can always try:
>
> *$ sudo dmesg | less*
>
> OR
>
> *$ tail /var/log/messages*
>
> To see what may be happening. If that does not work, then maybe you can 
> use *strace* to debug candump. 
>
> http://www.cyberciti.biz/tips/linux-strace-command-examples.html
>
> On Sat, Apr 11, 2015 at 11:07 AM, John Dammeyer <[email protected] 
> <javascript:>> wrote:
>
>> I'm a little late on this discussion but since I have lots of CAN 
>> experience and I'm also working on getting CAN working on my Beagle so I 
>> thought I'd jump in.
>> I bought the Logic Supply CBB_Serial with the on board CAN driver.
>> I followed the instructions on page 14 of their Serial Cape Manual with 
>> the only exception that I had to change to 
>> git clone https://github.com/linux-can/can-utils.git from the git://
>> gitorious.org site.
>>
>> I've always suggested when working with CAN in embedded systems the 
>> easiest solution is to have on hand one working functional CAN module.  
>> Ideally something like a CANUSB from Lawicel or one of the other dongles.  
>> The ability to generate well formed correctly timed messages can save you 
>> hours of time.
>>
>> Since I had a working system I set the bit rate up to 250kbps becauseI 
>> was attaching to a CANOpen system.  I'd done the ip link command at the 
>> start of the instruction sheet and now had to first 
>> ifconfig can0 down
>> then redo the bit rate
>> ip link set can0 up type can bitrate 250000
>> finally
>> ifconfig can0 up
>>
>> Imagine my surprise when I got a dump of the correct messages after 
>> running 
>> candump can0.
>>
>> Next step was to attach onto a project with custom CAN messages running 
>> 1Mbps.   Same process but with 1000000 for bit rate.
>>
>> In this case the host sends a block of messages for RGBW LED Lamp 
>> intensity to nodes 2 through 96 in even ID# increments because the odd node 
>> also receives the even node message and uses the second 4 bytes of each 
>> message for LED information.  
>>
>> Once every loop it waits a bit, then sends out a request to one specific 
>> node for node status; like temperature and bus voltage.  Then starts the 
>> whole refresh cycle again.  The example from candump is below.
>>
>> root@beaglebone:~# candump -t d -n 12000 can0 >logfile_can.txt
>> root@beaglebone:~# nano logfile_can.txt
>>
>>  (000.000124)  can0  290   [8]  FC D3 40 FF FC D3 40 FF
>>  (000.000126)  can0  294   [8]  FC D3 40 FF FC D3 40 FF
>>  (000.000113)  can0  298   [8]  FC D3 40 FF FC D3 40 FF
>>  (000.000110)  can0  296   [8]  FC D3 40 FF FC D3 40 FF  <-- last node 
>> polled
>>  (000.001741)  can0  446   [1]  28  <-- Command for lamp status.
>>  (000.008456)  can0  546   [8]  28 D3 28 02 00 00 77 70  <-- Reply from 
>> lamp 0x46
>>  (000.020936)  can0  202   [8]  FC D3 40 FF FC D3 40 FF  <-- polling 
>> starts again.
>>  (000.000085)  can0  204   [8]  FC D3 40 FF FC D3 40 FF
>>  (000.000140)  can0  208   [8]  FC D3 40 FF FC D3 40 FF
>>
>> However, I'm running into problems that completely crash the beagle.  I 
>> run candump continuously rather than for a set number of messages.   The 4 
>> leds freeze. A power cycle is the only solution. 
>> This happens when I use PuTTY from my WIN7 PC and the USB port and after 
>> a while the messages stop and it locks up.  That could be a Windows problem 
>> since the USB port interface could lock up the beagle.
>>
>> Next step was hard wired Ethernet to 192.168.0.125 and PuTTY.  Now it 
>> appears to run without issues messages streaming by.
>> But, if I try to open any other session into the beagle via web and Cloud 
>> 9 I can get in but at some point the system locks up and freezes.  
>> Especially if I close the browser.
>>
>> My first guess is I shouldn't be running candump as root since the cloud 
>> 9 also logs in as root.  Can it be as simple as that?  But why would the 
>> system lock up?  
>>
>> -- 
>> For more options, visit http://beagleboard.org/discuss
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to [email protected] <javascript:>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to