I put BBB to send data via DCAN_TX but the problem is that the CBB-Cape don't output nothing (and I have other BBB with the same cape, running candump). To make the BBB send something I used the RobertCNelson guide (above) and created this script:
#!/bin/bash wget http://www.pengutronix.de/software/libsocketcan/download/libsocketcan-0.0.10.tar.bz2 tar xvjf libsocketcan-0.0.10.tar.bz2 cd libsocketcan-0.0.10 ./autogen.sh ./configure --prefix=/usr make make install wget http://pengutronix.de/software/socket-can/download/canutils/v4.0/canutils-4.0.6.tar.bz2 tar xvjf canutils-4.0.6.tar.bz2 cd canutils-4.0.6 ./autogen.sh ./configure --prefix=/usr make make install It installed the most "recent" version of both. The canconfig was: canconfig can0 bitrate 1000000 ctrlmode triple-sampling on loopback off listen-only off restart-ms 50 Without the restart-ms the BBB DCAN always go to BUS-OFF state. In loopback tests it didn't happen. On Wed, Jun 10, 2015 at 4:35 PM, Bruno Luiz <[email protected]> wrote: > 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 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.
