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]
> <mailto:[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]
>     <mailto:[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]
> <mailto:[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.

Reply via email to