[beagleboard] Unable to use CAN bus on BBBL with 4.14.65-ti-r72 kernel (August image)
All, I'm having some trouble getting CAN bus to work on a Beaglbone Blue with an image from this August, with the 4.14.65-ti-r72 kernel. I verified that my hardware is correct by swapping in an older image (old enough to still use the capemgr!) based one the 4.9.45-ti-r57 kernel and verifying that works. With the newer kernel, I don't get any inbound traffic through candump and every time I call cansend the can0 interface goes down and I get the following error message in my dmesg output: [ 778.698672] c_can_platform 481d.can can0: bus-off The relevant lines in /boot/uEnv.txt are as follows: ###U-Boot Overlays### ###Master Enable enable_uboot_overlays=1 ### ###Overide capes with eeprom uboot_overlay_addr0=/lib/firmware/BB-UART2-00A0.dtbo uboot_overlay_addr1=/lib/firmware/BB-UART5-00A0.dtbo uboot_overlay_addr2=/lib/firmware/BB-CAN1-00A0.dtbo ###PRUSS OPTIONS uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo ###Cape Universal Enable enable_uboot_cape_universal=1 ###U-Boot Overlays### Any suggestions for what might be preventing CAN from working with the newer image? -p -- Pierce Nichols Principal Engineer Logos Electromechanical, LLC -- 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/CAENK0PzUePHEqMRm3hPTfsMHhw0sgdhX6u%2Bk8eY4ib_a2qxfxw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Beaglebone Blue UART problems
All, I just created a new SD card for my Beaglebone Blue using the latest image... and now the UARTs don't work. I confirmed that it's not hardware by switching back to the old one and confirming that they still work. I can't access them either on /dev/ttyO* or on /dev/ttyS*. The old card has the full GUI installed while the new one is an IoT image. The /opt/scripts/tools/version.sh output for the new SD card: git:/opt/scripts/:[d16ec8fd0409933b1251c1c571b787477fafb0d4] eeprom:[A335BNLTBLA21717EL001089] model:[TI_AM335x_BeagleBone_Blue] dogtag:[BeagleBoard.org Debian Image 2018-08-23] bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 2018.03-2-gac9cce7c6a]:[location: dd MBR] kernel:[4.14.65-ti-r72] nodejs:[v6.14.4] uboot_overlay_options:[enable_uboot_overlays=1] uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo] uboot_overlay_options:[enable_uboot_cape_universal=1] pkg check: to individually upgrade run: [sudo apt install --only-upgrade ] pkg:[bb-cape-overlays]:[4.4.20180914.0-0rcnee0~stretch+20180914] pkg:[bb-wl18xx-firmware]:[1.20180517-0rcnee0~stretch+20180517] pkg:[kmod]:[23-2rcnee1~stretch+20171005] pkg:[librobotcontrol]:[1.0.2-git20180829.0-0rcnee0~stretch+20180830] pkg:[firmware-ti-connectivity]:[20170823-1rcnee1~stretch+20180328] groups:[debian : debian adm kmem dialout cdrom floppy audio dip video plugdev users systemd-journal i2c bluetooth netdev cloud9ide gpio pwm eqep admin spi tisdk weston-launch xenomai] cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 quiet] dmesg | grep pinctrl-single [1.049466] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 568 dmesg | grep gpio-of-helper And for the old: git:/opt/scripts/:[2ce750d881941c5189db9e189af90517e11c079f] eeprom:[A335BNLTBLA21717EL001089] dogtag:[BeagleBoard.org Debian Image 2017-08-31] bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 2017.09-rc2-2-g7c9353] kernel:[4.9.45-ti-r57] nodejs:[v6.14.4] uboot_overlay_options:[enable_uboot_overlays=1] uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo] uboot_overlay_options:[enable_uboot_cape_universal=1] pkg:[bb-cape-overlays]:[4.4.20180914.0-0rcnee0~stretch+20180914] pkg:[bb-wl18xx-firmware]:[1.20180517-0rcnee0~stretch+20180517] pkg:[firmware-ti-connectivity]:[20170823-1rcnee1~stretch+20180328] So... wtf is going on here? -p -- Pierce Nichols Principal Engineer Logos Electromechanical, LLC -- 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/CAENK0PyGPpd5JjFygWRCADrEExYMNk%2B1CRNPzVNQd_eiFKfBKA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Beaglebone Blue compass not working in DMP mode
Hi all, I already posted this to the Beaglebone group, but I noticed there's lots of traffic here about the Beaglebone Blue as well, so I'm cross posting in hopes of finding an answer. I'm having trouble getting the compass heading to work correctly in DMP mode on my Beaglebone Blue. I'm running with the default roboticscape overlay. -- I calibrated the magnetometer and gyroscope as directed here: http://www.strawsondesign.com/#!manual-imu -- I ran the rc_test_imu program and confirmed that the magnetometer is working correctly. -- I ran rc_test_dmp -m -c -t. When I did this, I noticed that the raw compass was stuck near either 0, +180, or -180 degrees, jumping between those points as I rotated the Blue around the Z axis. When left still, the filtered compass always converged to the value of the raw. I also tested to make sure the pitch and roll angles were sane, and they were. I tried rotating it around the X and Y axes as well as using the -o option to switch the IMU orientation. This did not materially change the compass behavior. Trying it without the -m or -c switches produced no change in behavior. It behaves as if the magnetometer was simply not being turned on in DMP mode. I double-checked the source code of rc_test_dmp and recompiled it to see if the bug was there, and got the same results. Any suggestions for what I can try next? My application is such I can get away with processing the raw values to get a compass heading, but it would be nice to be able to use the sensor fusion. I filed a github issue as well. -- Pierce Nichols Principal Engineer Logos Electromechanical, LLC -- 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/CAENK0PyMQbyoCWfsHDoJHNNxYk%2B3sE4MCyK8Kb3dCb2CS%3DgOcQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Setting UART speed on BBB Rev C
Thanks! It compiles... testing in the morning. :) -p On Mon, May 2, 2016 at 4:24 PM, William Hermans <yyrk...@gmail.com> wrote: > https://groups.google.com/forum/#!searchin/beagleboard/Problemas$20para$20comunicar$20com$20o$20Baud$20Rate$205760/beagleboard/GC0rKe6rM0g/13c1ngXF7owJ > > Read the posts by Peter Hurley > > On Mon, May 2, 2016 at 1:24 PM, Pierce Nichols <pie...@logos-electro.com> > wrote: >> >> Hi all, >> >> I posted this to the Beaglebone list as well, but it seems a bit dead >> so I'm reposting here. >> >> I would like to find a way to set the speed of the UARTs to something >> other than the standard speeds offered by termios. >> >> I'm running a BBB Rev C with Debian 8.3, stock kernel from >> beaglebone.org. I'm using the universal cape and config-pin for setup >> (because it works well enough, so far). I currently have it working >> with a serial speed of 115.2 kbps, but the listener can't handle any >> of the standard termios speeds above that. It can handle 250, 500, or >> 1000 kbps, however. How can I set the BBB UARTs to operate at one of >> those speeds? >> >> -p >> >> PS -- I've considered shifting over to SPI on the next hardware rev, >> but that will be a little bit and I'd like more speed now. >> >> -- >> Pierce Nichols >> Principal Engineer >> Logos Electromechanical, LLC >> >> -- >> 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/CAENK0Pz5t2FyDi-b42krTfZayFEUB_vBV%2BqqiKKFtz0NKFK0TQ%40mail.gmail.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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beagleboard/CALHSORr2KC9Aw0wzC_%2BsrBb9pGdZ-HYR%3DyzwBHtW6HWgXW0Pxg%40mail.gmail.com. > For more options, visit https://groups.google.com/d/optout. -- Pierce Nichols Principal Engineer Logos Electromechanical, LLC -- 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/CAENK0Pw1o1iJ6%2BC%3DcOXZhEPK9h8q4G2z0jN4cjvrVkFNyVmDMw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Setting UART speed on BBB Rev C
Hi all, I posted this to the Beaglebone list as well, but it seems a bit dead so I'm reposting here. I would like to find a way to set the speed of the UARTs to something other than the standard speeds offered by termios. I'm running a BBB Rev C with Debian 8.3, stock kernel from beaglebone.org. I'm using the universal cape and config-pin for setup (because it works well enough, so far). I currently have it working with a serial speed of 115.2 kbps, but the listener can't handle any of the standard termios speeds above that. It can handle 250, 500, or 1000 kbps, however. How can I set the BBB UARTs to operate at one of those speeds? -p PS -- I've considered shifting over to SPI on the next hardware rev, but that will be a little bit and I'd like more speed now. -- Pierce Nichols Principal Engineer Logos Electromechanical, LLC -- 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/CAENK0Pz5t2FyDi-b42krTfZayFEUB_vBV%2BqqiKKFtz0NKFK0TQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] rfkill
So... I have a BBB rev C with a wifi dongle. I downloaded the 8.3 disk image, started it, no channels blocked by rfkill when I first started with the new image. I was able to modify /etc/network/interfaces and connect to wifi. I then ran the apt-get update/upgrade combo. After that, I rebooted... and rfkill once again defaults to blocked. Suggetions? -p On Thu, Feb 4, 2016 at 4:55 PM, Robert Nelson <robertcnel...@gmail.com> wrote: > On Thu, Feb 4, 2016 at 5:11 PM, <gnori...@ucr.edu> wrote: >> Hi, >> >> To start with, I'm running Debian 8.2 with kernel version 4.1. I'm trying to >> get the wifi, wlan0 interface, to come up on boot, however rfkill is >> blocking it. I can get it working again by running rfkill unblock all and >> ifdown wlan0, ifup wlan0 however this setting doesn't persist on reboot. >> I've attempted writing a service to run the rfkill unblock all command at >> startup but it doesn't work very consistently. Regardless, there should be a >> built in way to prevent rfkill from ever blocking an interface. If anyone >> could help me out with this I'd greatly appreciate it. > > I pushed a systemd update to fix this rfkill problem for a few years.. > > Double check that you have the fix: > > sudo apt-get update > sudo apt-get upgrade > > 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 beagleboard+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- Pierce Nichols Principal Engineer Logos Electromechanical, LLC -- 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.
