This had me for the whole morning. I solved it eventually by reading the schematic - thanks for making that available. I've posted a message to the maintainer of the google doc with a suggestion on how to make the setup clearer with regard to the necessity of either 5v barrel jack or J4.
On Monday, 15 June 2015 17:21:51 UTC+2, Bruno Luiz wrote: > > After the BBB CANTX worked (as I reported above), I tried some other > things to discover why the transceiver was not generating any output. The > main issue which was causing trouble is that the CBB needs an 5V power > source connected to the BeagleBone. Now all is working fine and I did some > scripts and a small guide for other devs, available at > https://github.com/brnluiz/bbb-can-installer. > > Strange that 5V power source requirement was not alerted at the CBB-Serial > cape manual. I discovered that checking the electrical diagram, which took > time and could be alerted by the manufacturer. > > Other thing is that I tested the device without any CAN Device or 120 ohms > resistor at the CANH and CANL and it worked (I used an oscilloscope to > check it). The cape already provides a 120 resistor (R10). After that I > tried with some CAN devices here and it worked too. > > On Friday, June 12, 2015 at 6:21:02 PM UTC-3, Bruno Luiz wrote: >> >> 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] >> <javascript:>> 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] >> <javascript:>> 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] >> <javascript:>> 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] <javascript:> 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] <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] <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 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] <javascript:>. >> 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] <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]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/522d8db9-8176-4f38-8c0e-20b50633b360%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
