I checked that when I run any "cansend" or "cangen" the interface go to BUS_OFF state (with ip -details link show can0). I tried to install libsocketcan, but it didn't worked too. How I check if my kernel is configured rightly for SocketCAN?
On Monday, June 8, 2015 at 3:50:55 PM UTC-3, Bruno Luiz wrote: > > I ran "candump can0" in one BeagleBone and, at the other BBB, "cangen can0 > -D 11223344DEADBEEF -L 8". Both BBB had the same disk image (I just changed > the device IPs) and use the same cbb cape model. Each cape is connected > with a cutted ethernet cable, so the only thing that is not in the bus is > the 120 ohms parallel resistor. Well, after the commands it, didn't worked > (no logs or some output on osciloscope). > > ifconfig log: > > ############### candump device: > can0 Link encap:UNSPEC HWaddr > 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 > UP RUNNING NOARP MTU:16 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:10 > RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) > Interrupt:182 > > > ############### cangen device: > can0 Link encap:UNSPEC HWaddr > 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 > UP NOARP MTU:16 Metric:1 > RX packets:3 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:10 > RX bytes:24 (24.0 B) TX bytes:0 (0.0 B) > Interrupt:182 > > > The strangest thing was the "cat /proc/net/can/stats". When I was running > the "cangen device" it increases TXF, but the "candump device" change > nothing. I can't figure out what could be happening. The stats logs: > > ############### cangen device: > 5363 transmitted frames (TXF) # This increases > 3 received frames (RXF) > 0 matched frames (RXMF) > > 0 % total match ratio (RXMR) > 5 frames/s total tx rate (TXR) > 0 frames/s total rx rate (RXR) > > 0 % current match ratio (CRXMR) > 5 frames/s current tx rate (CTXR) > 0 frames/s current rx rate (CRXR) > > 0 % max match ratio (MRXMR) > 5 frames/s max tx rate (MTXR) > 3 frames/s max rx rate (MRXR) > > 0 current receive list entries (CRCV) > 0 maximum receive list entries (MRCV) > > > ############### candump device: > 0 transmitted frames (TXF) > 0 received frames (RXF) > 0 matched frames (RXMF) > > 0 % total match ratio (RXMR) > 0 frames/s total tx rate (TXR) > 0 frames/s total rx rate (RXR) > > 0 % current match ratio (CRXMR) > 0 frames/s current tx rate (CTXR) > 0 frames/s current rx rate (CRXR) > > 0 % max match ratio (MRXMR) > 0 frames/s max tx rate (MTXR) > 0 frames/s max rx rate (MRXR) > > 1 current receive list entries (CRCV) > 1 maximum receive list entries (MRCV) > > > On Tue, Jun 2, 2015 at 11:58 PM, evilwulfie <[email protected]> wrote: > >> Not much good to play with can with no other can bus things on the bus. >> If your writing >> software use Vcan and simulate your can device so you can get a jump >> programming your application >> until you have a device on your bus. >> >> >> >> >> >> >> On 6/2/2015 5:19 PM, William Hermans wrote: >> >> *Meanwhile, as your setup is almost the same of mine, could you run the >>> cangen and test the output (canh + gnd or canl + gnd) with an oscilloscope >>> to see if it transmits something without any CAN device?* >> >> >> No can do. The board is hooked up to an external CAN device. Logging >> data. >> >> On Tue, Jun 2, 2015 at 1:40 PM, Bruno Luiz <[email protected]> >> wrote: >> >>> My "dmesg | grep cape" seems right >>> >>> [ 3.373227] bone_capemgr bone_capemgr: Baseboard: >>> 'A335BNLT,000C,4014BBBK3429' >>> [ 3.373249] bone_capemgr bone_capemgr: >>> compatible-baseboard=ti,beaglebone-black >>> [ 3.433139] bone_capemgr bone_capemgr: slot #0: No cape found >>> [ 3.493138] bone_capemgr bone_capemgr: slot #1: No cape found >>> [ 3.553156] bone_capemgr bone_capemgr: slot #2: No cape found >>> [ 3.583214] bone_capemgr bone_capemgr: slot #3: >>> 'cape-CBB-Serial,r01,Logic Supply,cape-CBB-Serial' >>> [ 3.583478] bone_capemgr bone_capemgr: initialized OK. >>> [ 3.602192] bone_capemgr bone_capemgr: slot #3: dtbo >>> 'cape-CBB-Serial-r01.dtbo' loaded; overlay id #0 >>> >>> and my "lsmod" too >>> can_raw 5383 1 >>> can 26347 1 can_raw >>> omap_sham 18661 0 >>> omap_aes 12035 0 >>> usb_f_acm 6692 1 >>> u_serial 9442 3 usb_f_acm >>> usb_f_ecm 8898 1 >>> g_multi 5722 0 >>> usb_f_mass_storage 40017 2 g_multi >>> usb_f_rndis 21091 2 g_multi >>> u_ether 11080 3 usb_f_ecm,usb_f_rndis,g_multi >>> libcomposite 43102 5 >>> usb_f_acm,usb_f_ecm,usb_f_rndis,g_multi,usb_f_mass_storage >>> omap_rng 4188 0 >>> c_can_platform 6169 0 >>> rng_core 6965 1 omap_rng >>> c_can 9105 1 c_can_platform >>> can_dev 11344 1 c_can >>> uio_pdrv_genirq 3169 0 >>> uio 8006 1 uio_pdrv_genirq >>> >>> My "/sys/kernel/debug/pinctrl/44e10800.pinmux/pingroups" >>> >>> registered pin groups: >>> group: pinmux_clkout2_pin >>> pin 109 (44e109b4.0) >>> >>> group: pinmux_uart0_pins >>> pin 92 (44e10970.0) >>> pin 93 (44e10974.0) >>> >>> group: nxp_hdmi_bonelt_pins >>> pin 108 (44e109b0.0) >>> pin 40 (44e108a0.0) >>> pin 41 (44e108a4.0) >>> pin 42 (44e108a8.0) >>> pin 43 (44e108ac.0) >>> pin 44 (44e108b0.0) >>> pin 45 (44e108b4.0) >>> pin 46 (44e108b8.0) >>> pin 47 (44e108bc.0) >>> pin 48 (44e108c0.0) >>> pin 49 (44e108c4.0) >>> pin 50 (44e108c8.0) >>> pin 51 (44e108cc.0) >>> pin 52 (44e108d0.0) >>> pin 53 (44e108d4.0) >>> pin 54 (44e108d8.0) >>> pin 55 (44e108dc.0) >>> pin 56 (44e108e0.0) >>> pin 57 (44e108e4.0) >>> pin 58 (44e108e8.0) >>> pin 59 (44e108ec.0) >>> >>> group: nxp_hdmi_bonelt_off_pins >>> pin 108 (44e109b0.0) >>> >>> group: pinmux_mmc1_pins >>> pin 88 (44e10960.0) >>> >>> group: pinmux_emmc_pins >>> pin 32 (44e10880.0) >>> pin 33 (44e10884.0) >>> pin 0 (44e10800.0) >>> pin 1 (44e10804.0) >>> pin 2 (44e10808.0) >>> pin 3 (44e1080c.0) >>> pin 4 (44e10810.0) >>> pin 5 (44e10814.0) >>> pin 6 (44e10818.0) >>> pin 7 (44e1081c.0) >>> >>> group: user_leds_s0 >>> pin 21 (44e10854.0) >>> pin 22 (44e10858.0) >>> pin 23 (44e1085c.0) >>> pin 24 (44e10860.0) >>> >>> group: pinmux_i2c0_pins >>> pin 98 (44e10988.0) >>> pin 99 (44e1098c.0) >>> >>> group: pinmux_i2c2_pins >>> pin 94 (44e10978.0) >>> pin 95 (44e1097c.0) >>> >>> group: nxp_hdmi_bonelt_pins >>> pin 108 (44e109b0.0) >>> pin 40 (44e108a0.0) >>> pin 41 (44e108a4.0) >>> pin 42 (44e108a8.0) >>> pin 43 (44e108ac.0) >>> pin 44 (44e108b0.0) >>> pin 45 (44e108b4.0) >>> pin 46 (44e108b8.0) >>> pin 47 (44e108bc.0) >>> pin 48 (44e108c0.0) >>> pin 49 (44e108c4.0) >>> pin 50 (44e108c8.0) >>> pin 51 (44e108cc.0) >>> pin 52 (44e108d0.0) >>> pin 53 (44e108d4.0) >>> pin 54 (44e108d8.0) >>> pin 55 (44e108dc.0) >>> pin 56 (44e108e0.0) >>> pin 57 (44e108e4.0) >>> pin 58 (44e108e8.0) >>> pin 59 (44e108ec.0) >>> >>> group: nxp_hdmi_bonelt_off_pins >>> pin 108 (44e109b0.0) >>> >>> group: cpsw_default >>> pin 66 (44e10908.0) >>> pin 67 (44e1090c.0) >>> pin 68 (44e10910.0) >>> pin 69 (44e10914.0) >>> pin 70 (44e10918.0) >>> pin 71 (44e1091c.0) >>> pin 72 (44e10920.0) >>> pin 73 (44e10924.0) >>> pin 74 (44e10928.0) >>> pin 75 (44e1092c.0) >>> pin 76 (44e10930.0) >>> pin 77 (44e10934.0) >>> pin 78 (44e10938.0) >>> pin 79 (44e1093c.0) >>> pin 80 (44e10940.0) >>> >>> group: cpsw_sleep >>> pin 66 (44e10908.0) >>> pin 67 (44e1090c.0) >>> pin 68 (44e10910.0) >>> pin 69 (44e10914.0) >>> pin 70 (44e10918.0) >>> pin 71 (44e1091c.0) >>> pin 72 (44e10920.0) >>> pin 73 (44e10924.0) >>> pin 74 (44e10928.0) >>> pin 75 (44e1092c.0) >>> pin 76 (44e10930.0) >>> pin 77 (44e10934.0) >>> pin 78 (44e10938.0) >>> pin 79 (44e1093c.0) >>> pin 80 (44e10940.0) >>> >>> group: davinci_mdio_default >>> pin 82 (44e10948.0) >>> pin 83 (44e1094c.0) >>> >>> group: davinci_mdio_sleep >>> pin 82 (44e10948.0) >>> pin 83 (44e1094c.0) >>> >>> group: pinmux_bb_uart2_pins >>> pin 85 (44e10954.0) >>> pin 84 (44e10950.0) >>> >>> group: pinmux_bb_uart4_pins >>> pin 28 (44e10870.0) >>> pin 29 (44e10874.0) >>> pin 16 (44e10840.0) >>> pin 34 (44e10888.0) >>> >>> group: pinmux_dcan1_pins >>> pin 97 (44e10984.0) >>> pin 96 (44e10980.0) >>> >>> >>> On Tuesday, June 2, 2015 at 5:32:48 PM UTC-3, Bruno Luiz wrote: >>>> >>>> Well, testing it with the oscilloscope, following the Robert Nelson >>>> guide, it didn't worked. It is very strange that nothing is outputted >>>> while >>>> I am probing the CANH/CANL/GND channels, as I did with the DSP (with the >>>> DSP it worked). I am going to try to find some CAN device here to test it, >>>> but I still think that is strange. >>>> >>>> Meanwhile, as your setup is almost the same of mine, could you run >>>> the cangen and test the output (canh + gnd or canl + gnd) with an >>>> oscilloscope to see if it transmits something without any CAN device? >>>> >>>> PS: the buffer didn't got full when without CAN devices, as the >>>> manual said that would happen. Although, in earlier tests, when I was >>>> without the cape (I tested right off the DCAN1 pins) this problem happened. >>>> >>>> On Monday, June 1, 2015 at 9:28:38 PM UTC-3, William Hermans wrote: >>>>> >>>>> According to the Logic Supply serial cape manual . . . >>>>> >>>>> *Important:* >>>>>> >>>>>> *You cannot just test the CAN Bus software without connecting the >>>>>> CBB-Serial hardware to another CAN device. You need to be connected to >>>>>> a >>>>>> receiving CAN device so that ACK (acknowledge) packets get sent and the >>>>>> CAN >>>>>> sender can mark it as sent (i.e. stop buffering it), otherwise the >>>>>> buffer >>>>>> gets full after a short period of time and all future writes to the CAN >>>>>> Bus >>>>>> will fail.* >>>>>> >>>>> >>>>> We've pretty much duplicated the exact steps you've done with the >>>>> exception of connecting the beaglebone + serial cape to an external CAN >>>>> device. We've also tested kernels 3.8.x, 3.14.x, and 4.1.x( most recently >>>>> ). They all work. Most curious though . . >>>>> >>>>> >>>>> >>>>> *I am working with a BeagleBone Black rev C for a project using CAN. >>>>> I am using the CBB-Serial-r02 cape because we need the UART features too* >>>>> >>>>> We're using . . . >>>>> >>>>> >>>>> [email protected] password: >>>>> Last login: Mon May 11 20:23:49 2015 from 192.168.7.1 >>>>> debian@beaglebone:~$ cat /sys/devices/platform/bone_capemgr/slots >>>>> 0: 54:P---L *cape-CBB-Serial,r01,Logic Supply,cape-CBB-Serial* >>>>> 1: 55:PF--- >>>>> 2: 56:PF--- >>>>> 3: 57:PF--- >>>>> >>>>> >>>>> Curious because you say you're using an r2, where we're using and >>>>> r1. Is this a Logic Supply board ? >>>>> >>>>> On Mon, Jun 1, 2015 at 12:10 PM, Robert Nelson <[email protected]> >>>>> wrote: >>>>> >>>>>> On Mon, Jun 1, 2015 at 1:16 PM, <[email protected]> wrote: >>>>>> > I am working with a BeagleBone Black rev C for a project using CAN. >>>>>> I am >>>>>> > using the CBB-Serial-r02 cape because we need the UART features >>>>>> too. The >>>>>> > problem is that CAN is not working. I did a lot of things to test >>>>>> it on a >>>>>> > 3.8-rt kernel from RobertCNelson (which is only PREEMPT), but it >>>>>> didn't >>>>>> > worked at all. Some things that I did: >>>>>> > >>>>>> > 1) Always modprobe the can modules (can, can-dev, can-raw) >>>>>> > 2) Compiled and installed canutils, always using the "cangen can0" >>>>>> to test >>>>>> > the can output >>>>>> > 3) Always run "ip link set can0 up type can bitrate 125000; >>>>>> ifconfig can0 >>>>>> > up" to activate can0 >>>>>> > 4) Installed the CBB-Serial-r02 dtbs from the official repository, >>>>>> even that >>>>>> > the debian image that I used already includes it >>>>>> > 5) Test the output with an osciloscope. I did the same test with an >>>>>> EzDSP >>>>>> > 28335 and it worked, so it is not a problem with this part of the >>>>>> method >>>>>> > 6) I tried to do a candump can0 with the DSP generating random >>>>>> data, but the >>>>>> > candump didn't show any data >>>>>> > >>>>>> > I recompiled 3.14 kernel using the dtb-rebuilder (instructions on >>>>>> this >>>>>> > tutorial: >>>>>> > >>>>>> https://groups.google.com/d/msg/beagleboard/_9u1B6ZkgCU/K2ARgwfC490J) >>>>>> and >>>>>> > enabling the DCAN1 (because DCAN0 disables the I2C used for >>>>>> capemgr) and it >>>>>> > didn't worked too. >>>>>> > >>>>>> > Well, I ran out of options here. Some one is having problems with >>>>>> the rev C >>>>>> > and CAN too or that is some problem with my method? >>>>>> >>>>>> No reason to double post to the group. ;) >>>>>> >>>>>> can0/can1 works on 3.14/4.1.x >>>>>> >>>>>> Right now i'd recommend you use v4.1.x and utilze cape overlays.. >>>>>> >>>>>> Step 1: update kernel: >>>>>> >>>>>> sudo apt-get update >>>>>> sudo apt-get install linux-image-4.1.0-rc6-bone5 >>>>>> sudo reboot >>>>>> >>>>>> Step 2: clone overlay repo: >>>>>> >>>>>> git clone https://github.com/beagleboard/bb.org-overlays >>>>>> cd ./bb.org-overlays >>>>>> >>>>>> Update dtc: >>>>>> ./dtc-overlay.sh >>>>>> >>>>>> Install overlays: >>>>>> ./install.sh >>>>>> >>>>>> reboot.. >>>>>> >>>>>> the CBB-Serial-r02 cape should be auto-detected.. if not, please >>>>>> reply with: >>>>>> >>>>>> dmesg | grep cape >>>>>> >>>>>> So i can add it.. >>>>>> >>>>>> Regards, >>>>>> >>>>>> -- >>>>>> Robert Nelson >>>>>> https://rcn-ee.com/ >>>>>> >>>>>> -- >>>>>> 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. >>>>>> >>>>> >>>>> -- >>> 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. >>> >> >> -- >> 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. >> >> >> -- >> For more options, visit http://beagleboard.org/discuss >> --- >> You received this message because you are subscribed to a topic in the >> Google Groups "BeagleBoard" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/beagleboard/n5lkTW8R3Xo/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Bruno Luiz da Silva - *http://brunoluiz.net <http://brunoluiz.net>* > Desenvolvedor de software @ *CES/CERTI > <http://www.certi.org.br/pt/ces-servicos>* > Co-fundador @ NeoViz (*http://neoviz.com.br* <http://neoviz.com.br/>) > Desenvolvedor Web freelance > Celular: (48) 9621-1021 | Skype: brnluiz > -- 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.
