RE: [beagleboard] Re: BBB- DCAN1 problems using latest debian image
I have no idea what this dongle would cost but they claim linux compatibility. https://can-newsletter.org/hardware/host-interfaces/171102_with-up-to-four-can-fd-channels_intrepid/=cwt17-44 <https://can-newsletter.org/hardware/host-interfaces/171102_with-up-to-four-can-fd-channels_intrepid/=cwt17-44_medium=cwt-mail_campaign=weekly-telegraph-17-44> _medium=cwt-mail_campaign=weekly-telegraph-17-44 As for your question about both CAN working. It all depends on what other I/O is enabled. Perhaps this link will help. http://www.embedded-things.com/bbb/enable-canbus-on-the-beaglebone-black/ John From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On Behalf Of Tracy Smith Sent: November-01-17 9:10 AM To: beagleboard@googlegroups.com Subject: Re: [beagleboard] Re: BBB- DCAN1 problems using latest debian image Hi John, Both CANS are working on BBB even though Robert Nelson is implementing these on the P9 expansion header? So what indicates the second CAN is working fine on BBB? What do I look for to see the second CAN is working properly? If this is the case, I just need to validate both are working and save myself time. We only saw the first CAN working. Thx, Tracy On Nov 1, 2017, at 10:33 AM, John Dammeyer <jo...@autoartisans.com> wrote: CAN1 and CAN2 are available when you aren’t using any other cape and I think eiher HDMI or perhaps it’s the LCD interface. It’s been a while. There is no relationship between /dev/ttyUSB0 and the CAN devices. One requires a CAN driver to function while the other is purely a serial port like a UART. To get 5 CAN ports I chose the Freescale 9S12 series. I think ST Micro also makes an ARM compatible processor with 4 CAN ports. There aren’t a lot around. If you want higher speed access along with message interrupts than what you can get with USB FTDI based CAN connections your alternative approach will be to add Microchip MCP2515s on board and use the SPI bus interface. With 3 select lines to a 3:8 mux you can select one of 4 CAN devices, and wire-OR the interrupts. You just have to poll which one caused the interrupt. I believe there is a driver for the MCP2515 already in the Beagle CAN library. Alternatively, since you are already building a cape that has CAN drivers on it and you now you want at least 2 more CAN devices it may be easier to use a second processor that has two CAN ports. Write the firmware to look like an SPI based MCP2515 and you can use the stock Beagle CAN driver for it. In fact, use either the ST Micro ARM and make all the CAN ports on it appear as if they were MCP2515s and that then frees up your other pins on the Beagle. John From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On Behalf Of Tracy Smith Sent: November-01-17 2:51 AM To: beagleboard@googlegroups.com Subject: Re: [beagleboard] Re: BBB- DCAN1 problems using latest debian image Hi John, Do you see support for both CAN0 and CAN1? Need both and our pins for CAN1 are E17 and E18 in the TI pinmux tool. Found the pad names and pins in uboot pinmux for CAN0 after this post. Haven’t found pad names associated with E17/E18 yet in uboot pinmux. Will look at the kernel dts today. My question I guess will CAN1 be available when plugging in the CANUSB and where do you see CAN1 indicated? If supported, it will appear as /dev/ttyUSB1? Or, as a different device on the BBB? Eventually may need as many as four CAN0-3. Thx, Tracy On Oct 31, 2017, at 8:00 PM, John Dammeyer <jo...@autoartisans.com> wrote: The CANUSB from Lawicel is a standard USB device that looks like a serial port since it can use the FTDI driver. On my MachineKit Debian Beagle 2.0 when I plug in the CANUSB I find I have a /dev/ttyUSB0 device. I installed putty and connected to /dev/ttyUSB0 In the terminal window V with a CR returns V1011 An S5 sets 250kbps An O opens the port. t12327788 with a CR again of course sends SID=123, DLC=2, Data 0x77 0x88 With nothing connected to the CANUSB the red LED goes on. (or if bitrate is wrong). A C closes the port. An F prints the error flags and shuts off the red led. It’s a good idea to have auto line feed set in putty so that each received message is on a new line. John Dammeyer From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On Behalf Of Tracy Smith Sent: October-31-17 3:42 PM To: BeagleBoard Subject: [beagleboard] Re: BBB- DCAN1 problems using latest debian image Hi John, I'm attempting to enable CAN support for a USB/CAN from a Lawicel. We have a custom board and need to use pin D17/D18 and E17/E18 for CAN1 and CAN2. The pad names in u-boot/arch/arm/include/asm/arch-am33xx/mux_am33xx.h for the BBB includes i2c0_sda (pin C17) and i2c0_scl (pin C16), but I don't see names for i2c2_scl (pin D17) and i2c2_sda (pin D18), nor tstpt1 (pin E17) nor TP9 (pin E18), 1. Did I miss the names for these pins in u-boot?
Re: [beagleboard] Re: BBB- DCAN1 problems using latest debian image
Hi John, Both CANS are working on BBB even though Robert Nelson is implementing these on the P9 expansion header? So what indicates the second CAN is working fine on BBB? What do I look for to see the second CAN is working properly? If this is the case, I just need to validate both are working and save myself time. We only saw the first CAN working. Thx, Tracy > On Nov 1, 2017, at 10:33 AM, John Dammeyer <jo...@autoartisans.com> wrote: > > CAN1 and CAN2 are available when you aren’t using any other cape and I think > eiher HDMI or perhaps it’s the LCD interface. It’s been a while. There is > no relationship between /dev/ttyUSB0 and the CAN devices. One requires a CAN > driver to function while the other is purely a serial port like a UART. > > To get 5 CAN ports I chose the Freescale 9S12 series. I think ST Micro also > makes an ARM compatible processor with 4 CAN ports. There aren’t a lot > around. > > If you want higher speed access along with message interrupts than what you > can get with USB FTDI based CAN connections your alternative approach will be > to add Microchip MCP2515s on board and use the SPI bus interface. With 3 > select lines to a 3:8 mux you can select one of 4 CAN devices, and wire-OR > the interrupts. You just have to poll which one caused the interrupt. I > believe there is a driver for the MCP2515 already in the Beagle CAN library. > > Alternatively, since you are already building a cape that has CAN drivers on > it and you now you want at least 2 more CAN devices it may be easier to use a > second processor that has two CAN ports. Write the firmware to look like an > SPI based MCP2515 and you can use the stock Beagle CAN driver for it. > > In fact, use either the ST Micro ARM and make all the CAN ports on it appear > as if they were MCP2515s and that then frees up your other pins on the Beagle. > > John > > > From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On > Behalf Of Tracy Smith > Sent: November-01-17 2:51 AM > To: beagleboard@googlegroups.com > Subject: Re: [beagleboard] Re: BBB- DCAN1 problems using latest debian image > > Hi John, > > Do you see support for both CAN0 and CAN1? Need both and our pins for CAN1 > are E17 and E18 in the TI pinmux tool. Found the pad names and pins in uboot > pinmux for CAN0 after this post. Haven’t found pad names associated with > E17/E18 yet in uboot pinmux. Will look at the kernel dts today. > > My question I guess will CAN1 be available when plugging in the CANUSB and > where do you see CAN1 indicated? If supported, it will appear as > /dev/ttyUSB1? Or, as a different device on the BBB? Eventually may need as > many as four CAN0-3. > > Thx, Tracy > > On Oct 31, 2017, at 8:00 PM, John Dammeyer <jo...@autoartisans.com> wrote: > > The CANUSB from Lawicel is a standard USB device that looks like a serial > port since it can use the FTDI driver. > > On my MachineKit Debian Beagle 2.0 when I plug in the CANUSB I find I have a > /dev/ttyUSB0 device. > I installed putty and connected to /dev/ttyUSB0 > In the terminal window > V with a CR returns > V1011 > An S5 sets 250kbps > An O opens the port. > t12327788 with a CR again of course sends SID=123, DLC=2, Data 0x77 0x88 > With nothing connected to the CANUSB the red LED goes on. (or if bitrate is > wrong). > A C closes the port. > An F prints the error flags and shuts off the red led. > > It’s a good idea to have auto line feed set in putty so that each received > message is on a new line. > John Dammeyer > > > > From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On > Behalf Of Tracy Smith > Sent: October-31-17 3:42 PM > To: BeagleBoard > Subject: [beagleboard] Re: BBB- DCAN1 problems using latest debian image > > Hi John, > > I'm attempting to enable CAN support for a USB/CAN from a Lawicel. We have a > custom board and need to use pin D17/D18 and E17/E18 for CAN1 and CAN2. > > The pad names in u-boot/arch/arm/include/asm/arch-am33xx/mux_am33xx.h for the > BBB includes i2c0_sda (pin C17) and i2c0_scl (pin C16), but I don't see names > for i2c2_scl (pin D17) and i2c2_sda (pin D18), nor tstpt1 (pin E17) nor TP9 > (pin E18), > > 1. Did I miss the names for these pins in u-boot? > > 2. If u-boot does not support these pins, should they be added to u-boot, > and/or added to the kernel to support these pins? > > Should these pins be pinmuxed in both uboot and the kernel, or only in the > kernel dts? Checking now to see if the kernel has support for these pins. > > thx, Tracy > > On Wednesday, April 8, 2015 at 8:20:29 AM UTC-5, Mark Irwin wr
Re: [beagleboard] Re: BBB- DCAN1 problems using latest debian image
Hi John, Do you see support for both CAN0 and CAN1? Need both and our pins for CAN1 are E17 and E18 in the TI pinmux tool. Found the pad names and pins in uboot pinmux for CAN0 after this post. Haven’t found pad names associated with E17/E18 yet in uboot pinmux. Will look at the kernel dts today. My question I guess will CAN1 be available when plugging in the CANUSB and where do you see CAN1 indicated? If supported, it will appear as /dev/ttyUSB1? Or, as a different device on the BBB? Eventually may need as many as four CAN0-3. Thx, Tracy > On Oct 31, 2017, at 8:00 PM, John Dammeyer <jo...@autoartisans.com> wrote: > > The CANUSB from Lawicel is a standard USB device that looks like a serial > port since it can use the FTDI driver. > > On my MachineKit Debian Beagle 2.0 when I plug in the CANUSB I find I have a > /dev/ttyUSB0 device. > I installed putty and connected to /dev/ttyUSB0 > In the terminal window > V with a CR returns > V1011 > An S5 sets 250kbps > An O opens the port. > t12327788 with a CR again of course sends SID=123, DLC=2, Data 0x77 0x88 > With nothing connected to the CANUSB the red LED goes on. (or if bitrate is > wrong). > A C closes the port. > An F prints the error flags and shuts off the red led. > > It’s a good idea to have auto line feed set in putty so that each received > message is on a new line. > John Dammeyer > > > > From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On > Behalf Of Tracy Smith > Sent: October-31-17 3:42 PM > To: BeagleBoard > Subject: [beagleboard] Re: BBB- DCAN1 problems using latest debian image > > Hi John, > > I'm attempting to enable CAN support for a USB/CAN from a Lawicel. We have a > custom board and need to use pin D17/D18 and E17/E18 for CAN1 and CAN2. > > The pad names in u-boot/arch/arm/include/asm/arch-am33xx/mux_am33xx.h for the > BBB includes i2c0_sda (pin C17) and i2c0_scl (pin C16), but I don't see names > for i2c2_scl (pin D17) and i2c2_sda (pin D18), nor tstpt1 (pin E17) nor TP9 > (pin E18), > > 1. Did I miss the names for these pins in u-boot? > > 2. If u-boot does not support these pins, should they be added to u-boot, > and/or added to the kernel to support these pins? > > Should these pins be pinmuxed in both uboot and the kernel, or only in the > kernel dts? Checking now to see if the kernel has support for these pins. > > thx, Tracy > > On Wednesday, April 8, 2015 at 8:20:29 AM UTC-5, Mark Irwin wrote: > Hi, > > I have been trying to build a proof of concept system using two beaglebone > black units with there DCAN1 (pins P9_24 and P9_26) and two can transcievers > TI SN65HVD251P. > The can transceivers are powered from the same 5V bench supply as both of the > beaglebone blacks. the canh and canl pins are terminated at both ends by 120R > resistors to ensure the 60R bus impedence. > > I was following the instructions in other posts about updating to the latest > debian version and then upgrading the kernel to 3.14. This i have done. > uname -a > Linux beaglebone 3.14.35-ti-rt-r56 #1 SMP PREEMPT Sun Mar 29 01:13:05 UTC > 2015 armv7l GNU/Linux > > I added dtb=am335x-boneblack-can1.dtb to the uEnv.txt > > I have also installed the canbus tools within the image so i can attempt a > cangen can0 and candump can0. > > On system boot i am doing the following: > > modprobe can > modprobe can-dev > modprobe can-raw > > ip link set can0 type can bitrate 125000 triple-sampling on > ifconfig can0 up > > however if i use candump can0 and cangen can0 within two seperate putty > sessions i dont see anything. > > If I create a vcan bus i do see the messages in loopback. > sudo modprobe vcan > sudo ip link add dev vcan0 type vcan > sudo ifconfig vcan0 up > > Previously I was using an older debian image and found that when i ran cangen > can0 that the buffer would give me an error that it was full. however now > with the latest image i am not getting the bufer full message but still not > seeing anything on the candump. What should i expect to see here? > > Can anyone see where I have gone wrong or a step i am missing? > > Thanks in advance. > > Mark > > -- > 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/_9u1B6ZkgCU/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > beagleboard+unsubscr...@googlegroups.com. > To view this discussion on the web
RE: [beagleboard] Re: BBB- DCAN1 problems using latest debian image
The CANUSB from Lawicel is a standard USB device that looks like a serial port since it can use the FTDI driver. On my MachineKit Debian Beagle 2.0 when I plug in the CANUSB I find I have a /dev/ttyUSB0 device. I installed putty and connected to /dev/ttyUSB0 In the terminal window V with a CR returns V1011 An S5 sets 250kbps An O opens the port. t12327788 with a CR again of course sends SID=123, DLC=2, Data 0x77 0x88 With nothing connected to the CANUSB the red LED goes on. (or if bitrate is wrong). A C closes the port. An F prints the error flags and shuts off the red led. It’s a good idea to have auto line feed set in putty so that each received message is on a new line. John Dammeyer From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On Behalf Of Tracy Smith Sent: October-31-17 3:42 PM To: BeagleBoard Subject: [beagleboard] Re: BBB- DCAN1 problems using latest debian image Hi John, I'm attempting to enable CAN support for a USB/CAN from a Lawicel. We have a custom board and need to use pin D17/D18 and E17/E18 for CAN1 and CAN2. The pad names in u-boot/arch/arm/include/asm/arch-am33xx/mux_am33xx.h for the BBB includes i2c0_sda (pin C17) and i2c0_scl (pin C16), but I don't see names for i2c2_scl (pin D17) and i2c2_sda (pin D18), nor tstpt1 (pin E17) nor TP9 (pin E18), 1. Did I miss the names for these pins in u-boot? 2. If u-boot does not support these pins, should they be added to u-boot, and/or added to the kernel to support these pins? Should these pins be pinmuxed in both uboot and the kernel, or only in the kernel dts? Checking now to see if the kernel has support for these pins. thx, Tracy On Wednesday, April 8, 2015 at 8:20:29 AM UTC-5, Mark Irwin wrote: Hi, I have been trying to build a proof of concept system using two beaglebone black units with there DCAN1 (pins P9_24 and P9_26) and two can transcievers TI SN65HVD251P. The can transceivers are powered from the same 5V bench supply as both of the beaglebone blacks. the canh and canl pins are terminated at both ends by 120R resistors to ensure the 60R bus impedence. I was following the instructions in other posts about updating to the latest debian version and then upgrading the kernel to 3.14. This i have done. uname -a Linux beaglebone 3.14.35-ti-rt-r56 #1 SMP PREEMPT Sun Mar 29 01:13:05 UTC 2015 armv7l GNU/Linux I added dtb=am335x-boneblack-can1.dtb to the uEnv.txt I have also installed the canbus tools within the image so i can attempt a cangen can0 and candump can0. On system boot i am doing the following: modprobe can modprobe can-dev modprobe can-raw ip link set can0 type can bitrate 125000 triple-sampling on ifconfig can0 up however if i use candump can0 and cangen can0 within two seperate putty sessions i dont see anything. If I create a vcan bus i do see the messages in loopback. sudo modprobe vcan sudo ip link add dev vcan0 type vcan sudo ifconfig vcan0 up Previously I was using an older debian image and found that when i ran cangen can0 that the buffer would give me an error that it was full. however now with the latest image i am not getting the bufer full message but still not seeing anything on the candump. What should i expect to see here? Can anyone see where I have gone wrong or a step i am missing? Thanks in advance. Mark -- 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/_9u1B6ZkgCU/unsubscribe. To unsubscribe from this group and all its topics, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/e6297438-0999-4320-916e-f41d74671533%40googlegroups.com <https://groups.google.com/d/msgid/beagleboard/e6297438-0999-4320-916e-f41d74671533%40googlegroups.com?utm_medium=email_source=footer> . 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 beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/003001d352ac%24d3f24980%247bd6dc80%24%40autoartisans.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: BBB- DCAN1 problems using latest debian image
Hi John, I'm attempting to enable CAN support for a USB/CAN from a Lawicel. We have a custom board and need to use pin D17/D18 and E17/E18 for CAN1 and CAN2. The pad names in u-boot/arch/arm/include/asm/arch-am33xx/mux_am33xx.h for the BBB includes i2c0_sda (pin C17) and i2c0_scl (pin C16), but I don't see names for i2c2_scl (pin D17) and i2c2_sda (pin D18), nor tstpt1 (pin E17) nor TP9 (pin E18), 1. Did I miss the names for these pins in u-boot? 2. If u-boot does not support these pins, should they be added to u-boot, and/or added to the kernel to support these pins? Should these pins be pinmuxed in both uboot and the kernel, or only in the kernel dts? Checking now to see if the kernel has support for these pins. thx, Tracy On Wednesday, April 8, 2015 at 8:20:29 AM UTC-5, Mark Irwin wrote: > > Hi, > > I have been trying to build a proof of concept system using two beaglebone > black units with there DCAN1 (pins P9_24 and P9_26) and two can > transcievers TI SN65HVD251P. > The can transceivers are powered from the same 5V bench supply as both of > the beaglebone blacks. the canh and canl pins are terminated at both ends > by 120R resistors to ensure the 60R bus impedence. > > I was following the instructions in other posts about updating to the > latest debian version and then upgrading the kernel to 3.14. This i have > done. > uname -a > Linux beaglebone 3.14.35-ti-rt-r56 #1 SMP PREEMPT Sun Mar 29 01:13:05 UTC > 2015 armv7l GNU/Linux > > I added dtb=am335x-boneblack-can1.dtb to the uEnv.txt > > I have also installed the canbus tools within the image so i can attempt a > cangen can0 and candump can0. > > On system boot i am doing the following: > > modprobe can > modprobe can-dev > modprobe can-raw > > ip link set can0 type can bitrate 125000 triple-sampling on > ifconfig can0 up > > however if i use candump can0 and cangen can0 within two seperate putty > sessions i dont see anything. > > If I create a vcan bus i do see the messages in loopback. > sudo modprobe vcan > sudo ip link add dev vcan0 type vcan > sudo ifconfig vcan0 up > > Previously I was using an older debian image and found that when i ran > cangen can0 that the buffer would give me an error that it was full. > however now with the latest image i am not getting the bufer full message > but still not seeing anything on the candump. What should i expect to see > here? > > Can anyone see where I have gone wrong or a step i am missing? > > Thanks in advance. > > Mark > > -- 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 beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/e6297438-0999-4320-916e-f41d74671533%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: BBB- DCAN1 problems using latest debian image
@John D Which kernel version are you running on the black ? kernel version 3.14.x is supposed to bring some USB, and ethernet improvements over kernel version 3.8.x. However, I'm not sure what exactly these improvement are. Anyhow, it was a thought while reading your post. I do know that early on with kernel 3.8.x if you tried to hotplug ethernet or USB, you'd get a kernel panic. Symptoms similar to what you're explaining here, You'd try to hotplug, everything would work fine for around a minute, then the board / system would just freeze. Another thought that I had was that you may be powering over USB only ? Perhaps you are not getting enough power. You can always try: *$ sudo dmesg | less* OR *$ tail /var/log/messages* To see what may be happening. If that does not work, then maybe you can use *strace* to debug candump. http://www.cyberciti.biz/tips/linux-strace-command-examples.html On Sat, Apr 11, 2015 at 11:07 AM, John Dammeyer jo...@autoartisans.com wrote: I'm a little late on this discussion but since I have lots of CAN experience and I'm also working on getting CAN working on my Beagle so I thought I'd jump in. I bought the Logic Supply CBB_Serial with the on board CAN driver. I followed the instructions on page 14 of their Serial Cape Manual with the only exception that I had to change to git clone https://github.com/linux-can/can-utils.git from the git:// gitorious.org site. I've always suggested when working with CAN in embedded systems the easiest solution is to have on hand one working functional CAN module. Ideally something like a CANUSB from Lawicel or one of the other dongles. The ability to generate well formed correctly timed messages can save you hours of time. Since I had a working system I set the bit rate up to 250kbps becauseI was attaching to a CANOpen system. I'd done the ip link command at the start of the instruction sheet and now had to first ifconfig can0 down then redo the bit rate ip link set can0 up type can bitrate 25 finally ifconfig can0 up Imagine my surprise when I got a dump of the correct messages after running candump can0. Next step was to attach onto a project with custom CAN messages running 1Mbps. Same process but with 100 for bit rate. In this case the host sends a block of messages for RGBW LED Lamp intensity to nodes 2 through 96 in even ID# increments because the odd node also receives the even node message and uses the second 4 bytes of each message for LED information. Once every loop it waits a bit, then sends out a request to one specific node for node status; like temperature and bus voltage. Then starts the whole refresh cycle again. The example from candump is below. root@beaglebone:~# candump -t d -n 12000 can0 logfile_can.txt root@beaglebone:~# nano logfile_can.txt (000.000124) can0 290 [8] FC D3 40 FF FC D3 40 FF (000.000126) can0 294 [8] FC D3 40 FF FC D3 40 FF (000.000113) can0 298 [8] FC D3 40 FF FC D3 40 FF (000.000110) can0 296 [8] FC D3 40 FF FC D3 40 FF -- last node polled (000.001741) can0 446 [1] 28 -- Command for lamp status. (000.008456) can0 546 [8] 28 D3 28 02 00 00 77 70 -- Reply from lamp 0x46 (000.020936) can0 202 [8] FC D3 40 FF FC D3 40 FF -- polling starts again. (000.85) can0 204 [8] FC D3 40 FF FC D3 40 FF (000.000140) can0 208 [8] FC D3 40 FF FC D3 40 FF However, I'm running into problems that completely crash the beagle. I run candump continuously rather than for a set number of messages. The 4 leds freeze. A power cycle is the only solution. This happens when I use PuTTY from my WIN7 PC and the USB port and after a while the messages stop and it locks up. That could be a Windows problem since the USB port interface could lock up the beagle. Next step was hard wired Ethernet to 192.168.0.125 and PuTTY. Now it appears to run without issues messages streaming by. But, if I try to open any other session into the beagle via web and Cloud 9 I can get in but at some point the system locks up and freezes. Especially if I close the browser. My first guess is I shouldn't be running candump as root since the cloud 9 also logs in as root. Can it be as simple as that? But why would the system lock up? -- 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 beagleboard+unsubscr...@googlegroups.com. 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 beagleboard+unsubscr...@googlegroups.com. For more options, visit
[beagleboard] Re: BBB- DCAN1 problems using latest debian image
I'm a little late on this discussion but since I have lots of CAN experience and I'm also working on getting CAN working on my Beagle so I thought I'd jump in. I bought the Logic Supply CBB_Serial with the on board CAN driver. I followed the instructions on page 14 of their Serial Cape Manual with the only exception that I had to change to git clone https://github.com/linux-can/can-utils.git from the git://gitorious.org site. I've always suggested when working with CAN in embedded systems the easiest solution is to have on hand one working functional CAN module. Ideally something like a CANUSB from Lawicel or one of the other dongles. The ability to generate well formed correctly timed messages can save you hours of time. Since I had a working system I set the bit rate up to 250kbps becauseI was attaching to a CANOpen system. I'd done the ip link command at the start of the instruction sheet and now had to first ifconfig can0 down then redo the bit rate ip link set can0 up type can bitrate 25 finally ifconfig can0 up Imagine my surprise when I got a dump of the correct messages after running candump can0. Next step was to attach onto a project with custom CAN messages running 1Mbps. Same process but with 100 for bit rate. In this case the host sends a block of messages for RGBW LED Lamp intensity to nodes 2 through 96 in even ID# increments because the odd node also receives the even node message and uses the second 4 bytes of each message for LED information. Once every loop it waits a bit, then sends out a request to one specific node for node status; like temperature and bus voltage. Then starts the whole refresh cycle again. The example from candump is below. root@beaglebone:~# candump -t d -n 12000 can0 logfile_can.txt root@beaglebone:~# nano logfile_can.txt (000.000124) can0 290 [8] FC D3 40 FF FC D3 40 FF (000.000126) can0 294 [8] FC D3 40 FF FC D3 40 FF (000.000113) can0 298 [8] FC D3 40 FF FC D3 40 FF (000.000110) can0 296 [8] FC D3 40 FF FC D3 40 FF -- last node polled (000.001741) can0 446 [1] 28 -- Command for lamp status. (000.008456) can0 546 [8] 28 D3 28 02 00 00 77 70 -- Reply from lamp 0x46 (000.020936) can0 202 [8] FC D3 40 FF FC D3 40 FF -- polling starts again. (000.85) can0 204 [8] FC D3 40 FF FC D3 40 FF (000.000140) can0 208 [8] FC D3 40 FF FC D3 40 FF However, I'm running into problems that completely crash the beagle. I run candump continuously rather than for a set number of messages. The 4 leds freeze. A power cycle is the only solution. This happens when I use PuTTY from my WIN7 PC and the USB port and after a while the messages stop and it locks up. That could be a Windows problem since the USB port interface could lock up the beagle. Next step was hard wired Ethernet to 192.168.0.125 and PuTTY. Now it appears to run without issues messages streaming by. But, if I try to open any other session into the beagle via web and Cloud 9 I can get in but at some point the system locks up and freezes. Especially if I close the browser. My first guess is I shouldn't be running candump as root since the cloud 9 also logs in as root. Can it be as simple as that? But why would the system lock up? -- 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 beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: BBB- DCAN1 problems using latest debian image
Hi William, uname -r returns 3.8.13-bone47 from the revC board that arrived a couple of weeks ago. I'm running with a 2A supply since I as using a WiFi USB module. At the moment I'm hardwired again. Following the instructions in Derek Malloy's Exploring Beaglebone I created a user and a group. Also used visudo to add my user to the sudo file so I can run root stuff. Logged on as the user I've now had the 1Mbps CAN messages running for over 4 hours. I can log in with Chrome into Cloud9 and create a terminal which automatically logs in as root. No more lock ups. If I have more problems I'll start a new thread. Very strange. Thanks On Saturday, April 11, 2015 at 2:46:44 PM UTC-7, William Hermans wrote: @John D Which kernel version are you running on the black ? kernel version 3.14.x is supposed to bring some USB, and ethernet improvements over kernel version 3.8.x. However, I'm not sure what exactly these improvement are. Anyhow, it was a thought while reading your post. I do know that early on with kernel 3.8.x if you tried to hotplug ethernet or USB, you'd get a kernel panic. Symptoms similar to what you're explaining here, You'd try to hotplug, everything would work fine for around a minute, then the board / system would just freeze. Another thought that I had was that you may be powering over USB only ? Perhaps you are not getting enough power. You can always try: *$ sudo dmesg | less* OR *$ tail /var/log/messages* To see what may be happening. If that does not work, then maybe you can use *strace* to debug candump. http://www.cyberciti.biz/tips/linux-strace-command-examples.html On Sat, Apr 11, 2015 at 11:07 AM, John Dammeyer jo...@autoartisans.com javascript: wrote: I'm a little late on this discussion but since I have lots of CAN experience and I'm also working on getting CAN working on my Beagle so I thought I'd jump in. I bought the Logic Supply CBB_Serial with the on board CAN driver. I followed the instructions on page 14 of their Serial Cape Manual with the only exception that I had to change to git clone https://github.com/linux-can/can-utils.git from the git:// gitorious.org site. I've always suggested when working with CAN in embedded systems the easiest solution is to have on hand one working functional CAN module. Ideally something like a CANUSB from Lawicel or one of the other dongles. The ability to generate well formed correctly timed messages can save you hours of time. Since I had a working system I set the bit rate up to 250kbps becauseI was attaching to a CANOpen system. I'd done the ip link command at the start of the instruction sheet and now had to first ifconfig can0 down then redo the bit rate ip link set can0 up type can bitrate 25 finally ifconfig can0 up Imagine my surprise when I got a dump of the correct messages after running candump can0. Next step was to attach onto a project with custom CAN messages running 1Mbps. Same process but with 100 for bit rate. In this case the host sends a block of messages for RGBW LED Lamp intensity to nodes 2 through 96 in even ID# increments because the odd node also receives the even node message and uses the second 4 bytes of each message for LED information. Once every loop it waits a bit, then sends out a request to one specific node for node status; like temperature and bus voltage. Then starts the whole refresh cycle again. The example from candump is below. root@beaglebone:~# candump -t d -n 12000 can0 logfile_can.txt root@beaglebone:~# nano logfile_can.txt (000.000124) can0 290 [8] FC D3 40 FF FC D3 40 FF (000.000126) can0 294 [8] FC D3 40 FF FC D3 40 FF (000.000113) can0 298 [8] FC D3 40 FF FC D3 40 FF (000.000110) can0 296 [8] FC D3 40 FF FC D3 40 FF -- last node polled (000.001741) can0 446 [1] 28 -- Command for lamp status. (000.008456) can0 546 [8] 28 D3 28 02 00 00 77 70 -- Reply from lamp 0x46 (000.020936) can0 202 [8] FC D3 40 FF FC D3 40 FF -- polling starts again. (000.85) can0 204 [8] FC D3 40 FF FC D3 40 FF (000.000140) can0 208 [8] FC D3 40 FF FC D3 40 FF However, I'm running into problems that completely crash the beagle. I run candump continuously rather than for a set number of messages. The 4 leds freeze. A power cycle is the only solution. This happens when I use PuTTY from my WIN7 PC and the USB port and after a while the messages stop and it locks up. That could be a Windows problem since the USB port interface could lock up the beagle. Next step was hard wired Ethernet to 192.168.0.125 and PuTTY. Now it appears to run without issues messages streaming by. But, if I try to open any other session into the beagle via web and Cloud 9 I can get in but at some point the system locks up and freezes. Especially if I close the browser. My first guess is I shouldn't be running candump
[beagleboard] Re: BBB- DCAN1 problems using latest debian image
Hi Mark, On my system I have dtb=am335x-boneblack.dtb, I don't think you should comment it out. Are you using *both *can0 and can1? You should enable just the one you need. If you are using can0 you must comment out i2c2: cape eeprom because it uses the same pins. Regards, Rui On Wednesday, April 8, 2015 at 2:20:29 PM UTC+1, Mark Irwin wrote: Hi, I have been trying to build a proof of concept system using two beaglebone black units with there DCAN1 (pins P9_24 and P9_26) and two can transcievers TI SN65HVD251P. The can transceivers are powered from the same 5V bench supply as both of the beaglebone blacks. the canh and canl pins are terminated at both ends by 120R resistors to ensure the 60R bus impedence. I was following the instructions in other posts about updating to the latest debian version and then upgrading the kernel to 3.14. This i have done. uname -a Linux beaglebone 3.14.35-ti-rt-r56 #1 SMP PREEMPT Sun Mar 29 01:13:05 UTC 2015 armv7l GNU/Linux I added dtb=am335x-boneblack-can1.dtb to the uEnv.txt I have also installed the canbus tools within the image so i can attempt a cangen can0 and candump can0. On system boot i am doing the following: modprobe can modprobe can-dev modprobe can-raw ip link set can0 type can bitrate 125000 triple-sampling on ifconfig can0 up however if i use candump can0 and cangen can0 within two seperate putty sessions i dont see anything. If I create a vcan bus i do see the messages in loopback. sudo modprobe vcan sudo ip link add dev vcan0 type vcan sudo ifconfig vcan0 up Previously I was using an older debian image and found that when i ran cangen can0 that the buffer would give me an error that it was full. however now with the latest image i am not getting the bufer full message but still not seeing anything on the candump. What should i expect to see here? Can anyone see where I have gone wrong or a step i am missing? Thanks in advance. Mark -- 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 beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: BBB- DCAN1 problems using latest debian image
Hi Rui, I have reverted the changes to uEmv to comment out the #dtb line I then modified am335x-boneblack.dts to uncomment so that it looks like the following: /*can0: P9.19, P9.20: disable: i2c2: cape eeprom */ /* can0: peripheral */ #include am335x-can0.dtsi /* can0: pinmux */ #include am335x-bone-can0.dtsi /* can1: P9_24, P9_26 */ #include am335x-can1.dtsi #include am335x-bone-can1.dtsi I built the dtb using dtb-rebuilder and copied the new am335x-boneblack.dtb to /boot/dtbs/3.14.35-ti-rt-r56/ and rebooted the system. Now when i look in the /sys/kernel/debug/pinctrl/44e10800.pinmux/pinmux-pins pin 94 (44e10978.0): P9_20_pinmux.47 (GPIO UNCLAIMED) function pinmux_P9_20_i2c_pin group pinmux_P9_20_i2c_pin pin 95 (44e1097c.0): P9_19_pinmux.46 (GPIO UNCLAIMED) function pinmux_P9_19_i2c_pin group pinmux_P9_19_i2c_pin pin 96 (44e10980.0): P9_26_pinmux.53 (GPIO UNCLAIMED) function pinmux_P9_26_can_pin group pinmux_P$ pin 97 (44e10984.0): P9_24_pinmux.51 (GPIO UNCLAIMED) function pinmux_P9_24_can_pin group pinmux_P$ It seems that the DCAN0 is still associated with i2c and not can0. However I can now use ip link set can1 type can bitrate 125000 triple-sampling on loopback on ip link set can0 type can bitrate 125000 triple-sampling on loopback on and bring up both can devices. If i do candump can0 and cangen can0 i do see loopback messages however when connected with two transceivers one connected to can0 and other can1 and then running cangen can0 and candump can1 i dont get any transmitted bits. I tried using a scope on CANTX P9_26 to ground and find that nothing is coming out of this pin. I also found that running cangen can0 after a few seconds i am getting this error. cangen can0 write: No buffer space available could you give me a step by step from boot up to get the canbus running to see if there is something I am missing? Thanks Mark On Thursday, 9 April 2015 05:30:55 UTC+10, RFA wrote: Hi Mark, I would rebuild the device tree to make sure can0 is included. - Revert the changes to uEnv. - download Robert Nelson's dtb-rebuilder ( https://github.com/RobertCNelson/dtb-rebuilder) and checkout 3.14-ti. - edit am335x-boneblack.dts to include can0. - make am335x-boneblack.dtb and replace the original file in /boot/dtbs/3.14.35-ti-r56/ - reboot. Regards Rui On Wednesday, April 8, 2015 at 2:20:29 PM UTC+1, Mark Irwin wrote: Hi, I have been trying to build a proof of concept system using two beaglebone black units with there DCAN1 (pins P9_24 and P9_26) and two can transcievers TI SN65HVD251P. The can transceivers are powered from the same 5V bench supply as both of the beaglebone blacks. the canh and canl pins are terminated at both ends by 120R resistors to ensure the 60R bus impedence. I was following the instructions in other posts about updating to the latest debian version and then upgrading the kernel to 3.14. This i have done. uname -a Linux beaglebone 3.14.35-ti-rt-r56 #1 SMP PREEMPT Sun Mar 29 01:13:05 UTC 2015 armv7l GNU/Linux I added dtb=am335x-boneblack-can1.dtb to the uEnv.txt I have also installed the canbus tools within the image so i can attempt a cangen can0 and candump can0. On system boot i am doing the following: modprobe can modprobe can-dev modprobe can-raw ip link set can0 type can bitrate 125000 triple-sampling on ifconfig can0 up however if i use candump can0 and cangen can0 within two seperate putty sessions i dont see anything. If I create a vcan bus i do see the messages in loopback. sudo modprobe vcan sudo ip link add dev vcan0 type vcan sudo ifconfig vcan0 up Previously I was using an older debian image and found that when i ran cangen can0 that the buffer would give me an error that it was full. however now with the latest image i am not getting the bufer full message but still not seeing anything on the candump. What should i expect to see here? Can anyone see where I have gone wrong or a step i am missing? Thanks in advance. Mark -- 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 beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: BBB- DCAN1 problems using latest debian image
Hi Mark, That kernel version has no cape manager support. You have to rebuild the device tree. First revert the changes to uEnv. Then, download Robert Nelson's dtb-rebuilder ( https://github.com/RobertCNelson/dtb-rebuilder) and checkout 3.14-ti. Edit am335x-boneblack.dts to include can0. To conclude, make am335x-boneblack.dtb and replace the original file in /boot/dtbs/3.14.35-ti-r56/ Reboot. Let me know how it works. Regards Rui On Wednesday, April 8, 2015 at 2:20:29 PM UTC+1, Mark Irwin wrote: Hi, I have been trying to build a proof of concept system using two beaglebone black units with there DCAN1 (pins P9_24 and P9_26) and two can transcievers TI SN65HVD251P. The can transceivers are powered from the same 5V bench supply as both of the beaglebone blacks. the canh and canl pins are terminated at both ends by 120R resistors to ensure the 60R bus impedence. I was following the instructions in other posts about updating to the latest debian version and then upgrading the kernel to 3.14. This i have done. uname -a Linux beaglebone 3.14.35-ti-rt-r56 #1 SMP PREEMPT Sun Mar 29 01:13:05 UTC 2015 armv7l GNU/Linux I added dtb=am335x-boneblack-can1.dtb to the uEnv.txt I have also installed the canbus tools within the image so i can attempt a cangen can0 and candump can0. On system boot i am doing the following: modprobe can modprobe can-dev modprobe can-raw ip link set can0 type can bitrate 125000 triple-sampling on ifconfig can0 up however if i use candump can0 and cangen can0 within two seperate putty sessions i dont see anything. If I create a vcan bus i do see the messages in loopback. sudo modprobe vcan sudo ip link add dev vcan0 type vcan sudo ifconfig vcan0 up Previously I was using an older debian image and found that when i ran cangen can0 that the buffer would give me an error that it was full. however now with the latest image i am not getting the bufer full message but still not seeing anything on the candump. What should i expect to see here? Can anyone see where I have gone wrong or a step i am missing? Thanks in advance. Mark -- 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 beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: BBB- DCAN1 problems using latest debian image
Hi Mark, I would rebuild the device tree to make sure can0 is included. - Revert the changes to uEnv. - download Robert Nelson's dtb-rebuilder ( https://github.com/RobertCNelson/dtb-rebuilder) and checkout 3.14-ti. - edit am335x-boneblack.dts to include can0. - make am335x-boneblack.dtb and replace the original file in /boot/dtbs/3.14.35-ti-r56/ - reboot. Regards Rui On Wednesday, April 8, 2015 at 2:20:29 PM UTC+1, Mark Irwin wrote: Hi, I have been trying to build a proof of concept system using two beaglebone black units with there DCAN1 (pins P9_24 and P9_26) and two can transcievers TI SN65HVD251P. The can transceivers are powered from the same 5V bench supply as both of the beaglebone blacks. the canh and canl pins are terminated at both ends by 120R resistors to ensure the 60R bus impedence. I was following the instructions in other posts about updating to the latest debian version and then upgrading the kernel to 3.14. This i have done. uname -a Linux beaglebone 3.14.35-ti-rt-r56 #1 SMP PREEMPT Sun Mar 29 01:13:05 UTC 2015 armv7l GNU/Linux I added dtb=am335x-boneblack-can1.dtb to the uEnv.txt I have also installed the canbus tools within the image so i can attempt a cangen can0 and candump can0. On system boot i am doing the following: modprobe can modprobe can-dev modprobe can-raw ip link set can0 type can bitrate 125000 triple-sampling on ifconfig can0 up however if i use candump can0 and cangen can0 within two seperate putty sessions i dont see anything. If I create a vcan bus i do see the messages in loopback. sudo modprobe vcan sudo ip link add dev vcan0 type vcan sudo ifconfig vcan0 up Previously I was using an older debian image and found that when i ran cangen can0 that the buffer would give me an error that it was full. however now with the latest image i am not getting the bufer full message but still not seeing anything on the candump. What should i expect to see here? Can anyone see where I have gone wrong or a step i am missing? Thanks in advance. Mark -- 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 beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
