>
> *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.

Reply via email to