[beagleboard] Beaglebone Black Bluetooth capability

Does Beaglebone Black Wireless support APTX Low Latency Bluetooth? -- 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

[beagleboard] Re: Extended CAN (canfd) on BBB

If the headers on your BBB miss the canfd structures, you can assume the kernel does not include CAN-FD support. Adding them yourself does not magically make the kernel support it, even though your application supports it. Besides, are you aware than the integrated CAN controller of the BBB doe

[beagleboard] Re: Gadget Printer module g_printer Not Sending iPNPstring

I did get this working, by moving to Debian Jessie, kernel 4.x. This issue seems to be fixed in the later kernels. -- 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 t

Re: [beagleboard] Overlay does not create SPI pingroups with 4.4.21 kernel

Thanks for the info. I am not so sure about the need to update initramfs though. Just for yuks, I specified my custom overlay in uEnv.txt, and it seems to have loaded properly, which I confirmed by inspecting the output of dmesg. I am still verifying that my SPI ports work as expected (phase an

Re: [beagleboard] Overlay does not create SPI pingroups with 4.4.21 kernel

On Thursday, December 15, 2016 at 11:20:13 AM UTC-6, Phil wrote: > > I am having almost the identical issue with SPI as pbft, except that I am > running BBB's with *4.4.19-bone-rt-r13* and *4.4.38-bone-rt-r14*. I > assume these can be fixed as per your suggestion, but it appear

Re: [beagleboard] Overlay does not create SPI pingroups with 4.4.21 kernel

hould I proceed? Or is there some other problem entirely? Any guidance would be appreciated. Thanks, Phil -- 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

[beagleboard] Re: Trying to run the ADC from the PRU

Thanks, good catch! A question though: Under what circumstances would the ADC not start? I've been running the ADC now and have not had a startup fail. On Friday, September 23, 2016 at 7:57:06 AM UTC-5, TJF wrote: > > Hi Phil! > > Your code is incomplete. The error handling is

[beagleboard] Re: Trying to run the ADC from the PRU

Alright, I finally got this working, thanks to both William and TJF. In the end, my problem boils down to coding sloppiness on my part, as well as being constantly interrupted with other tasks. After spending a solid block of uninterrupted time doing some careful testing, the following code sni

Re: [beagleboard] Trying to run the ADC from the PRU

On Thursday, September 15, 2016 at 4:36:19 PM UTC-5, William Hermans wrote: > > The PRU hads to access the ADC through the L3_interconnect bus too . . . > so the control register for the L3_interconnect must also be enabled. > > That makes sense... But the TRM seems not to disclose the location

Re: [beagleboard] Trying to run the ADC from the PRU

On Wednesday, September 7, 2016 at 10:36:02 AM UTC-5, William Hermans wrote: > > The only thing I can think of is that you're not enabling the ADC control > register. Below is a code snippet from another post. > //Init ADC CTRL register > MOV r2, 0x44E0D040 > MOV r3, 0x0005 > SBB

[beagleboard] Re: Trying to run the ADC from the PRU

On Thursday, September 8, 2016 at 6:40:19 AM UTC-5, TJF wrote: > > Hi Phil! > > After boot the ADC subsystem is disabled by default. You have to enable > the CM_WKUP_ADC_TSC_CLKCTRL register in the CONTROL MODULE before you can > use it: > > mov r0, 0x44E004BC > mov

[beagleboard] Trying to run the ADC from the PRU

to be nonzero. Both my PRU code and the device tree overlay are shown below. I am running kernel 4.4.19-bone-rt-r13. Thanks, Phil *(BTW, this message is cross-posted here <https://groups.google.com/forum/#!category-topic/beaglebone/beagleboardorg-beaglebone-black/_NWi3J4uNxE>. It is not

[beagleboard] Re: I also get prussdrv_open() failure.... :(

I was so close! I found the problem! I forgot to do this: sudo cp pru_enable-00A0.dtbo /lib/firmware So, to summarize and wrap this up: 1. Use the device tree I posted previously, and name it pru_enable-00A0.dts 2. Build the dts file: dtc -O dtb -o pru_enable-00A0.dtbo -b 0 -@ pr

[beagleboard] I also get prussdrv_open() failure.... :(

As others have been reporting, I am getting a failure of prussdrv_open(). I have been poring and muddling over what others have posted, and still yet can't find the problem. Can anyone suggest anything? Thanks! Phil Relevant information: me@beaglebone:~/isp/sensor$ dmesg | grep -

Re: [beagleboard] Releasing the on-board EEPROM on i2c-0 / 0x50 from Kernel control?

ote: >> >>> william@beaglebone:~$ sudo dd count=30 bs=1 >>> if=/sys/bus/i2c/devices/0-0050/0-00500/nvmem >>> ▒U3▒A335BNLT00C03214BBBK0403▒▒30+0 records in >>> 30+0 records out >>> 30 bytes (30 B) copied, 0.0114076 s, 2.6 kB/s >>> >&

Re: [beagleboard] Releasing the on-board EEPROM on i2c-0 / 0x50 from Kernel control?

like to get around. On Tue, Aug 9, 2016 at 1:43 PM Gerald Coley wrote: > You will need to modify the hardware to remove the write protect before > you can do any writes.. > > Gerald > > On Tue, Aug 9, 2016 at 2:41 PM, Phil Mills wrote: > >> I'd like to

[beagleboard] Releasing the on-board EEPROM on i2c-0 / 0x50 from Kernel control?

I'd like to be able to read/write data from the BBB's on-board EEPROM programatically using the ioctl(...) interface just like any other i2c eeprom my software might be asked to go deal with. Of course the kernel claims that device for itself pretty quickly upon boot which means I can't get to

Re: [beagleboard] Working links to blank-EEPROM flasher image?

: > On Mon, Apr 18, 2016 at 9:51 AM, Phil Mills wrote: > >> Robert, >> >> It's been a while on this, but can you re-post the flasher img.xz >> someplace (bone-debian-7.8-lxde-4gb-armhf-2015-03-01-4gb.img.xz >> <http://rcn-ee.com/rootfs/bb.org/release/

Re: [beagleboard] Working links to blank-EEPROM flasher image?

t down from your website and my backup copy no longer validates correctly. Since this is actually a pretty valuable tool, is there a way that it could be posted up permanantly on one of the Beaglebone websites or GitHub pages? -phil On Tuesday, September 8, 2015 at 3:30:18 PM UTC-6, RobertCNels

Re: [beagleboard] Force a PRU output's default state to LOW as Device Tree loads

used on PRU pins) at that moment?* On Wed, Mar 30, 2016 at 9:32 AM Robert Nelson wrote: > On Wed, Mar 30, 2016 at 10:27 AM, Phil Mills wrote: > > Board spins eat up weeks of project - software / firmware changes are > > "free". ;-) > > > > ...so the powe

Re: [beagleboard] Force a PRU output's default state to LOW as Device Tree loads

d. > > On 3/30/2016 8:00 AM, Phil Mills wrote: > > I'm working with a Beaglebone Black to do some signal acquisition using a > laser as a light source. > > The sampling/acquisition system is driven through the PRU since I need > pretty tight timing - including pulsing

[beagleboard] Force a PRU output's default state to LOW as Device Tree loads

I'm working with a Beaglebone Black to do some signal acquisition using a laser as a light source. The sampling/acquisition system is driven through the PRU since I need pretty tight timing - including pulsing a laser to illuminate a sample. A problem that we just noticed is that as soon as I l

[beagleboard] Gadget Printer module g_printer Not Sending iPNPstring

got this working and if so which kernel version are you using. Phil Output of /usr/lib/cups/backend/usb on host with BBB plugged in. DEBUG: list_devices DEBUG: libusb_get_device_list=3 DEBUG: Switching USB device configuration: 0 -> 1 DEBUG: Failed to set configuration 1 for 04a9:1736 DEBUG2

Re: [beagleboard] Working links to blank-EEPROM flasher image?

the board. I think that's got me running - now to verify it on a few more boards in my pile. Much thanks, Robert. On Wednesday, September 9, 2015 at 11:59:03 AM UTC-6, RobertCNelson wrote: > > On Wed, Sep 9, 2015 at 12:52 PM, Phil Mills > wrote: > > Robert, > >

Re: [beagleboard] Working links to blank-EEPROM flasher image?

e connected 8. TP4 grounded to P8-1 9. Power applied via mini-USB cable 10. "" Suggestions or troubleshooting steps? I have erased/re-formatted/reloaded the cards 2x with same results. -phil On Tuesday, September 8, 2015 at 3:45:03 PM UTC-6, RobertCNelson wrote: > >

Re: [beagleboard] Working links to blank-EEPROM flasher image?

Silly, ain't it. >From the McAfee naughty-naughty screen: *URL Categories:* Malicious Sites, Personal Pages, Technical/Business Forums, Malicious Downloads *Reputation:* High Risk (127) -phil On Tuesday, September 8, 2015 at 4:08:44 PM UTC-6, Rick M wrote: > > > > On S

Re: [beagleboard] Working links to blank-EEPROM flasher image?

figuration sequence won't be any trouble at all. While I'm asking questions: is there a good reference script / utility to create an image file (.img.xz format) from an existing BBB ? -phil On Tuesday, September 8, 2015 at 4:04:40 PM UTC-6, RobertCNelson wrote: > > On Tue,

Re: [beagleboard] Working links to blank-EEPROM flasher image?

e EEPROM than what RCN's described? If so, I'd really appreciate a description of how YOU get to an unbootable BBB to a state where you can write to a blank/corrupted EEPROM. -phil On Tuesday, September 8, 2015 at 3:35:32 PM UTC-6, Gerald wrote: > > I2C writes is what we d

Re: [beagleboard] Working links to blank-EEPROM flasher image?

nformation to add to a wiki somewhere - I can't be the only person with blank (or inadvertently borked) BBB EEPROMs running around. -phil On Tuesday, September 8, 2015 at 3:30:18 PM UTC-6, RobertCNelson wrote: > > On Tue, Sep 8, 2015 at 4:15 PM, Phil Mills > wrote: > > I h

Re: [beagleboard] Working links to blank-EEPROM flasher image?

> the SRM, is still valid and is not stale or old. > > Gerald > > > On Tue, Sep 8, 2015 at 4:15 PM, Phil Mills > wrote: > >> I have inherited responsibility for a bunch of 3rd-party direct clones of >> a Beaglebone Black C5 (only known change is in silkscreening).

[beagleboard] Working links to blank-EEPROM flasher image?

I have inherited responsibility for a bunch of 3rd-party direct clones of a Beaglebone Black C5 (only known change is in silkscreening). Since none of these have any contents written to the onboard EEPROM, they fail to boot with "C" written to the serial console with no uSD card, and >

[beagleboard] Re: SCP / RSYNC stall out with "rcvd adjust [...]" notices - 2015-03-01 and 64-bit Wheezy host

twork staff towards would be helpful. On Thursday, June 25, 2015 at 5:05:59 PM UTC-6, Phil Mills wrote: > > Testing with various Windows SCP utilities fails in a similar way. The > transfer starts out fine and then rapidly throttles down to extinction. > > WinSCP, SmarTTY >

[beagleboard] Re: SCP / RSYNC stall out with "rcvd adjust [...]" notices - 2015-03-01 and 64-bit Wheezy host

Testing with various Windows SCP utilities fails in a similar way. The transfer starts out fine and then rapidly throttles down to extinction. WinSCP, SmarTTY -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Group

Re: [beagleboard] SCP / RSYNC stall out with "rcvd adjust [...]" notices - 2015-03-01 and 64-bit Wheezy host

Transfer using several Windows utilities (WinSCP and SmarTTY) fail similarly - the transfer starts out find and then throttles itself to exinction. On Thu, Jun 25, 2015 at 4:16 PM, Phil Mills wrote: > I have a Beaglebone Black with a fresh flash of the 2015-03-01 Debian > image (bone-

[beagleboard] SCP / RSYNC stall out with "rcvd adjust [...]" notices - 2015-03-01 and 64-bit Wheezy host

I have a Beaglebone Black with a fresh flash of the 2015-03-01 Debian image (bone-debian-7.8-lxde-4gb-armhf-2015-03-01-4gb.img) that I cannot scp or rsync large files to. >From my Wheezy 64-bit host VM, I try to scp a 27MB file to the Beaglebone via ethernet and the transfer stalls out after <1

[beagleboard] Re: Issue acessing pru_data_ram from Ubuntu

With kind regards Philipp Am Samstag, 11. April 2015 16:29:43 UTC+2 schrieb Phil W.: > > Hi, > > after implementing the ddr acces example from > https://github.com/sagedevices/am335x_pru_package/tree/master/pru_sw/example_apps/ddr_access > > into my project im

[beagleboard] Issue acessing pru_data_ram from Ubuntu

Hi, after implementing the ddr acces example from https://github.com/sagedevices/am335x_pru_package/tree/master/pru_sw/example_apps/ddr_access into my project im stuc at one point. In my User space code I do prussdrv_map_prumem(PRUSS0_PRU1_DATARAM, (void *) &info->pru_memory); if (in

[beagleboard] Really, how do I get started?

opment and make it run on and with the Debian distro that is factory installed on the BBB? I could ask lots more questions, but I think this provides a good picture of where I'm at with all this. Can anyone offer some guidance? Thanks! Phil -- For more options, visit http://beagleboard

[beagleboard] Re: Beaglebone Black and Web Servers?

(iii) Django can be installed. "apt-get install python-django" On Tuesday, 4 November 2014 11:40:21 UTC+11, Nick Apperley wrote: > > Have answers to some of your questions. See the replies below: > > (i) Apache > (ii)Linux (Debian or Ubuntu) > > Not sure if Django can be installed on the B

[beagleboard] Re: PRU C Project - from device tree to program execution

Um, and what about the data.bin file? I see you only use the text.bin file. Am Sonntag, 7. Dezember 2014 01:51:44 UTC+1 schrieb Phil W.: > > Hey Peter, > > thank you for your guide. > > Im a bit stuk with my own projekt. I wrote and succesfully debugged some > code for rea

[beagleboard] Re: PRU C Project - from device tree to program execution

Hey Peter, thank you for your guide. Im a bit stuk with my own projekt. I wrote and succesfully debugged some code for reading from an ADC with CCS and a JTAG probe. I also checked the shared ram mecanism for the host/PRU communication by manipulating it via Memory Browser. It works well from

[beagleboard] prussdrv_exec_program *** buffer overflow detected ***

Hey fellows, im using the code from shabaz BBB - High speed data acquisition and web-based UI article and I did a rewrite o

[beagleboard] SPI BBB Master, BBB Slave

I am having issues with SPI between two BBB that may be simple to solve. I have spidev_test loopback working on each board but am having problems connecting the two. spi0 master dts: 0x150 0x10 /* spi0_sclk, OUTPUT_PULLUP | MODE0 */ 0x154 0x30 /* spi0_d0, IN

[beagleboard] SPI BBB Master, BBB Slave

I am having issues with SPI between two BBB that may be simple to solve. I have spidev_test loopback working on each board but am having problems connecting the two. spi0 master dts: 0x150 0x10 /* spi0_sclk, OUTPUT_PULLUP | MODE0 */ 0x154 0x30 /* spi0_d0, I

Re: [beagleboard] Re: UART4 stopped working: did not get pins for uart4 error: -19

@44e0b000 44e10620-44e10623 : 4740.usb 44e10628-44e1062b : /ocp/usb@4740 44e10800-44e10a37 : /pinmux@44e10800 44e10800-44e10a37 : pinctrl-single ... Do you have any suggestions for how to clean up the kernel in this case? Thanks, Phil On Tuesday, April 8, 2014 4:00:47 PM UTC-5

Re: [beagleboard] Re: UART4 stopped working: did not get pins for uart4 error: -19

Robert, Yes, it is correctly passed to the kernel: ubuntu@ubuntu-armhf:~$ cat /proc/cmdline console=ttyO0,115200n8 fixrtc capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait Best regards, Phil On Tuesday, April 8, 2014 4:00:47 PM UTC-5

Re: [beagleboard] UART4 stopped working: did not get pins for uart4 error: -19

: 57:PF--- 4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G 5: ff:P-O-- Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI UART4 still doesn't work and the 'slots' still show an HDMI entry. Is this what you are suggesting or did I miss something? Any ideas w

[beagleboard] Re: UART4 stopped working: did not get pins for uart4 error: -19

t working under Ubuntu. There > seems to be pin error which may be preventing it from loading. I don't > know if this was caused by some configuration changes or not. I haven't > been able to figure out what is causing the conflict. > > How can I find and fix this prob

[beagleboard] UART4 stopped working: did not get pins for uart4 error: -19

don't know if this was caused by some configuration changes or not. I haven't been able to figure out what is causing the conflict. How can I find and fix this problem? Thanks for your h

[beagleboard] Re: Using the BeagleBoard Black instead of our outdated Data Hopper and Rabbit board for central control

Hello Troy, We may be able to help. Please send us you contact details at http://datavytals.com/?page_id=204 Thanks Phil On Wednesday, January 15, 2014 8:27:23 AM UTC-8, Troy wrote: > > Hello All, > > I am seeking help for a project that I have spent 6 years and nearly a >

[beagleboard] Black good for iscDHCP on Debian???

I'd like a small, cheap box to run Debian. This box will run ISC's DHCP implementation, and host a DHCP scope for a small LAN. Perhaps in the future, it will expand to a DNS server. I am new to Linux and the BeagleBone. Does this sound like a good use for the BeagleBone Black?? Thanks fo