Re: [beagleboard] Re: Beaglebone Black PRU Troubles

Hi Laurel, Yeah I have the -V3 flags sent. I think I found the issue that I was having. I may have misread the PRU Reference guide as well as the assembly language documentation on elinux. I had thought that the register address passed in the XIN and XOUT was what register in the PRU the

Re: [beagleboard] Re: Beaglebone Black PRU Troubles

Hi Zach, Are you compiling with the -V3 switch? This should enable the scratch pad correctly. I've had not problems with it this way. Laurel On Sun, Dec 4, 2016 at 9:03 PM, Zach B wrote: > Thanks Jason, those were two great examples. > > Has anyone had any trouble with the

Re: [beagleboard] Re: Beaglebone Black PRU Troubles

Thanks Jason, those were two great examples. Has anyone had any trouble with the scratch pad between PRUs? I'm using it to pass values between the two systems and it doesn't appear to be working at all. I even created a test script that has a PRU load a value into bank 0 and then read it back

Re: [beagleboard] Re: Beaglebone Black PRU Troubles

Thanks Jason, those were two great examples. Has anyone had any trouble with the scratch pad between PRUs? I'm using it to pass values between the two systems and it doesn't appear to be working at all. I even created a test script that has a PRU load a value into bank 0 and then read it back

Re: [beagleboard] Re: Beaglebone Black PRU Troubles

Greg, Yes, I'd like to get assembly only and mixed c and assembly examples in the support package using TI's compiler tools. I'd like to clean it up a bit and make it a little more useful first though. I put those examples together last night for you and Zach and figured I'd get them in your

Re: [beagleboard] Re: Beaglebone Black PRU Troubles

Hi Jason, this is awesome, much appreciated! Is it going to become part of the PRU Support Package examples? I'll run through the process soon and report on the result. I also have some questions on the interrupt examples for some time in the future. Meanwhile, I assume you ran the demo on a

Re: [beagleboard] Re: Beaglebone Black PRU Troubles

Greg and Zach, Check out the two tarballs in this drive link: https://drive.google.com/drive/folders/0B_OVOhSEksP8MDFiT0x6YU1EZG8?usp=sharing - PRU_Halt_Assembly.tar.gz - Contains a project to drop into /opt/source/pru-software-support-package/examples/am335x/ that is an

Re: [beagleboard] Re: Beaglebone Black PRU Troubles

Greg and Zach, Check out the two tarballs in this drive link: https://drive.google.com/drive/folders/0B_OVOhSEksP8MDFiT0x6YU1EZG8?usp=sharing - PRU_Halt_Assembly.tar.gz - Contains a project to drop into /opt/source/pru-software-support-package/examples/am335x/ that is an

Re: [beagleboard] Re: Beaglebone Black PRU Troubles

Greg and Zach, Check out the two tarballs in this drive link: https://drive.google.com/drive/folders/0B_OVOhSEksP8MDFiT0x6YU1EZG8?usp=sharing - PRU_Halt_Assembly.tar.gz - Contains a project to drop into /opt/source/pru-software-support-package/examples/am335x/ that is an

Re: [beagleboard] Re: Beaglebone Black PRU Troubles

I believe asmpru is the assembler code compiler which is part of the PRU compilation system which is described in the C/C++ Compiler manual. pasm is the older assembler which existed prior to the C compiler. There are differences in the assembly instructions used with pasm versus the more

Re: [beagleboard] Re: Beaglebone Black PRU Troubles

Greg, Thanks for the info. That linker primer helped a bit with what is exactly going on inside of the linker, at least to the level that I can understand. I'm still working through getting a single assembly file to work but for now I figured out a workaround with an empty c file. What is

Re: [beagleboard] Re: Beaglebone Black PRU Troubles

Here is a primer on linker files: http://processors.wiki.ti.com/index.php/Linker_Command_File_Primer I haven't done anything with assembly other than reverse engineer what it is doing. You can put assembly inline with your C code. That is described in the manual. There are "intrinsics" which

Re: [beagleboard] Re: Beaglebone Black PRU Troubles

I guess a better question would be, what libraries or other files need to be linked to create a file that will load and execute on the PRU? I can compile my code but the linking is a bit of a black box to me. I have been reading a lot of PRU reference documentation and haven't come across the

Re: [beagleboard] Re: Beaglebone Black PRU Troubles

Has anyone compiled a straight assembly file for the PRU? I know you can program in C but I can't accurately predict how long each C command takes to run and I have a time critical portion of my code. I have been attempting to use the clpru compiler but I keep getting linking errors as it is

Re: [beagleboard] Re: Beaglebone Black PRU Troubles

There are a few things to note on this subject. #1 https://github.com/cdsteinkuehler/beaglebone-universal-io/blob/master/config-pin#L522-L527 Of these 3 capes shown, only cape-universala will work unmodified. This is because this pin in the other two cape overlay's is commented out. #2 Going by

Re: [beagleboard] Re: Beaglebone Black PRU Troubles

Sorry for the deleted post I forgot a piece of information... So I'm not exactly sure what modifications I made that fixed my problem because I made a few and somewhere it resolved my issue. I ended up modifying the files listed below. I don't think I had to modify all of them but I figured I

Re: [beagleboard] Re: Beaglebone Black PRU Troubles

So I'm not exactly sure what modifications I made that fixed my problem because I made a few and somewhere it resolved my issue. I ended up modifying the files listed below. I don't think I had to modify all of them but I figured I would enable the pru_rproc for all variations of device trees

Re: [beagleboard] Re: Beaglebone Black PRU Troubles

On Sun, Nov 20, 2016 at 4:31 PM, Zach B wrote: > Thanks for the information Greg. > > Robert & everyone, > I was digging into that link you sent about which universal overlay gets > loaded at boot. I have tried modifying my uEnv.txt file to enable different > overlays but i

[beagleboard] Re: Beaglebone Black PRU Troubles

Thanks for the information Greg. Robert & everyone, I was digging into that link you sent about which universal overlay gets loaded at boot. I have tried modifying my uEnv.txt file to enable different overlays but i cant' seem to get config-pin to work for P9_31 and P9_29. It responds that

[beagleboard] Re: Beaglebone Black PRU Troubles

Excellent! It's challenging to get Remoteproc to work and remember it is still experimental, still evolving. So remember what works today may not work tomorrow when you update your OS. But I think that is more or less true with all of Linux! The only question I can even halfway answer is #1.

[beagleboard] Re: Beaglebone Black PRU Troubles

Thank you for all of the help Greg, I was finally able to get one of the examples to compile and execute. I'm still doing a bit of reading with regards to the reference manuals to figure out the proper registers and values for everything. I did have a few left over questions though. 1) Is

[beagleboard] Re: Beaglebone Black PRU Troubles

Go into the PRU support package examples directory. See if you can get the PRU_Halt to compile. This is the simplest possible C program for the PRU. All you have to do is the command make, and this will kick off the process. You will need to have the PRU_CGT environment variable set and also a

[beagleboard] Re: Beaglebone Black PRU Troubles

h that's my problem. I was only using pasm -b blink2.asm which doesn't link against anything. I had missed that because most of the other examples that I had read where using the UIO pru loader, which doesn't require any linking of the remoteproc. I had planned on switching to C in the

[beagleboard] Re: Beaglebone Black PRU Troubles

How did you compile the assembly code? The compilation has to be done with the Remoteproc and linker files. Remoteproc will look for certain code in the firmwares, and if it is not there, nothing will happen. On Friday, November 18, 2016 at 10:06:07 AM UTC-5, Zach B wrote: > > In trying to

[beagleboard] Re: Beaglebone Black PRU Troubles

In trying to test my code for the PRUs is there a good way to check and see if binary is being loaded into the PRU properly and check whether or not it is executing. I have a simple LED circuit running some basic blink code but nothing seems to be occurring. Also with everything activated, the

[beagleboard] Re: Beaglebone Black PRU Troubles

In trying to test my code for the PRUs is there a good way to check and see if binary is being loaded into the PRU properly and check whether or not it is executing. I have a simple LED circuit running some basic blink code but nothing seems to be occurring. Also with everything activated, the

[beagleboard] Re: Beaglebone Black PRU Troubles

Greg, Thanks for the link I to the motor controller. I actually ended up figuring out late last night what was preventing remote_proc from running properly. I had the line dtb=am335x-boneblack-overlay.dtb uncommented in my "uEnv.txt" file. I guess that device overlay prevented the remote_proc

[beagleboard] Re: Beaglebone Black PRU Troubles

Zach I think you mentioned you were interested in motor controllers: http://www.ti.com/lit/ug/tidubj6/tidubj6.pdf I just finished the Coursera course "Control of Mobile Robots". The course has some info on a Beaglebone based robot. I want to implement some, but probably not all. I'm going to be

[beagleboard] Re: Beaglebone Black PRU Troubles

Pretty much sounds correct. Did you create a file /etc/modprobe.d/pruss-blacklist.conf and the single line in this file is: blacklist uio_pruss Can you paste in your dts file change? Here is what I have: /* pruss: pick one: */ /* * /etc/modprobe.d/pruss-blacklist.conf * * blacklist

[beagleboard] Re: Beaglebone Black PRU Troubles

So I finally got some time to work with the PRUs again. I still seem to be having some issues with remoteproc. I got the c code for PRU0 to compile and I moved it to /lib/firmware under the correct name. I also followed the steps outlined in the e-linux exercise for enabling remote_proc as well

[beagleboard] Re: Beaglebone Black PRU Troubles

Remoteproc and RPMsg are kernel modules. Remoteproc/RPMsg live in the kernel, but they can communicate with user space via character device files and the sysfs virtual file system. The PRUSSDRV is totally different, not related to Remoteproc in any way to my knowledge. Best introductory page

[beagleboard] Re: Beaglebone Black PRU Troubles

I understand that bringing up GPIOs low is good practice. I meant when I set the P8_11 using "config-pin P8_11 pruout" the pin is automatically pulled high it appears. Is there a way to set it as a "pruout" but as a low pruout to start. It appears to be defaulting to "HI" mode when set to

Re: [beagleboard] Re: Beaglebone Black PRU Troubles

Cool, I'll be moving to that image, thanks for the heads up! Regards, Greg On Tuesday, November 15, 2016 at 10:49:41 AM UTC-5, Jason Kridner wrote: > > Shouldn't be any deltas, but can you use 2016-11-06 from > https://beagleboard.org/latest-images because we are standardizing on > that image

[beagleboard] Re: Beaglebone Black PRU Troubles

It's generally considered good design practice to bring up GPIOs low. But there are exceptions. I'm not sure what the PRU will do when it is disabled. I did the same thing months ago, and I do remember LEDs being lit or dimly lit after boot. Ultimately I got past that concern and it didn't

Re: [beagleboard] Re: Beaglebone Black PRU Troubles

> On Nov 15, 2016, at 8:06 AM, Greg wrote: > > > Just my advice, especially for a newbie PRU person (maybe even an experienced > one too), don't touch the Device Tree! At least not directly: > > https://github.com/cdsteinkuehler/beaglebone-universal-io > > (Note

[beagleboard] Re: Beaglebone Black PRU Troubles

Thanks for the detailed response that helped clear up a bit of confusion I was having. I've also been rereading through your pdf. I got the remote_proc up and running again. I started playing around with config-pin and "Universal IO" and was able to successfully toggle the pins how I wanted.

[beagleboard] Re: Beaglebone Black PRU Troubles

Just my advice, especially for a newbie PRU person (maybe even an experienced one too), don't touch the Device Tree! At least not directly: https://github.com/cdsteinkuehler/beaglebone-universal-io (Note the path to slots is not the same for 4x kernels) I've been using the Debian 8.6 IOT

[beagleboard] Re: Beaglebone Black PRU Troubles

Hey everyone so I took one step forward and one step back. With the last bit of help from Robert I was able to properly disable the universal overlay and load my own. It appears that my device overlay loads correctly. When I went to test things today however I can't seem to get the remote_proc

Re: [beagleboard] Re: Beaglebone Black PRU Troubles

Good news to report here, PRU ADC project working fine with the IOT image based on 4.4.27-ti-r62. I was trying the console image, but I am lazy and there was just too much stuff to install. So IOT it is. The only remaining mystery is why the firmwares do not start at boot. Removing and

Re: [beagleboard] Re: Beaglebone Black PRU Troubles

OK, I did not understand that about Universal IO overlays! Another question: I see the univ-emmc cape gets loaded after activating Remoteproc kernel modules. This is correct and expected behavior? I was a little surprised to see the coupling between device tree and kernel modules in this

Re: [beagleboard] Re: Beaglebone Black PRU Troubles

On Nov 12, 2016 10:39 AM, "Greg" wrote: > > Is there a better way to get the job done? Or better "don't touch that"? Yeap, the reliably way to unload the cape is to reboot.. this is why the cape universal with config-pin is so useful.. config-pin allows us to map a pin

Re: [beagleboard] Re: Beaglebone Black PRU Troubles

Is there a better way to get the job done? Or better "don't touch that"? On Saturday, November 12, 2016 at 11:17:58 AM UTC-5, RobertCNelson wrote: > > On Sat, Nov 12, 2016 at 8:13 AM, Greg > wrote: > > > Both images I tested this morning have unstable Device Trees. > >

Re: [beagleboard] Re: Beaglebone Black PRU Troubles

On Sat, Nov 12, 2016 at 8:13 AM, Greg wrote: > A general comment is that the Device Tree system is not robust! > I gave up on modifying Device Trees a long time ago. I'm using the > "Universal IO" whenever possible: > >

Re: [beagleboard] Re: Beaglebone Black PRU Troubles

A general comment is that the Device Tree system is not robust! I gave up on modifying Device Trees a long time ago. I'm using the "Universal IO" whenever possible: https://github.com/cdsteinkuehler/beaglebone-universal-io Avoid touching Device Tree files if you can! AVOID I just set up the

Re: [beagleboard] Re: Beaglebone Black PRU Troubles

On Fri, Nov 11, 2016 at 12:45 PM, Robert Nelson wrote: > >> univ-emmc is the userspace overlay we automatically load on bootup > >> > >> open /boot/uEnv.txt > >> > >> you'll notice a cape_universal=enable > >> > >> remove that and reboot > >> > >> Regards, > >> > > > >

Re: [beagleboard] Re: Beaglebone Black PRU Troubles

Hi Zach, So, first of all. Yes removing the line , commenting it out in uEnv.txt will keep from loading the overlay at boot. As for removing it from the initramfs, I would assume if you reversed the process. e.g. remove the line from uEnv.txt. then remove the file from /lib/firmware, that the

Re: [beagleboard] Re: Beaglebone Black PRU Troubles

Great, thanks! And not to be a pest but I assume in order to undo that change I simply comment the line that I add to the uEnv.txt and that's it? Should I worry about removing the *.dtbo object from the initrd? On Friday, November 11, 2016 at 3:22:17 PM UTC-5, RobertCNelson wrote: > > On Fri,

Re: [beagleboard] Re: Beaglebone Black PRU Troubles

On Fri, Nov 11, 2016 at 2:14 PM, Zach B wrote: > Thanks Robert! That solved the problem I have been having. The overlay > loaded and everything looks to be working. One follow up question I do have > is what is the proper way to load a custom overlay on startup? Is there a >

Re: [beagleboard] Re: Beaglebone Black PRU Troubles

Thanks Robert! That solved the problem I have been having. The overlay loaded and everything looks to be working. One follow up question I do have is what is the proper way to load a custom overlay on startup? Is there a way to enable multiple overlays as long as they don't try to use the same

Re: [beagleboard] Re: Beaglebone Black PRU Troubles

>> univ-emmc is the userspace overlay we automatically load on bootup >> >> open /boot/uEnv.txt >> >> you'll notice a cape_universal=enable >> >> remove that and reboot >> >> Regards, >> > > What does that actually do Robert ? I've done this myself in the past, and > haven't noticed a difference

Re: [beagleboard] Re: Beaglebone Black PRU Troubles

On Fri, Nov 11, 2016 at 12:26 PM, Robert Nelson wrote: > On Fri, Nov 11, 2016 at 12:53 PM, Zach B wrote: > > wow that is incredible useful, I didn't even realize that is what dmesg > did. > > Here is the output I got: > > [ 2117.571792] bone_capemgr

Re: [beagleboard] Re: Beaglebone Black PRU Troubles

On Fri, Nov 11, 2016 at 12:53 PM, Zach B wrote: > wow that is incredible useful, I didn't even realize that is what dmesg did. > Here is the output I got: > [ 2117.571792] bone_capemgr bone_capemgr: part_number 'PRU-GPIO-BLINK', > version 'N/A' > [ 2117.571876] bone_capemgr

Re: [beagleboard] Re: Beaglebone Black PRU Troubles

I just tried the various combinations of enabling and disabling the HDMI, emmc, both and neither and regardless of what it is set to I get a conflict on P8.11 every time. Is there a key component that I am missing somewhere or a different way I should be going about this? On Friday, November

Re: [beagleboard] Re: Beaglebone Black PRU Troubles

wow that is incredible useful, I didn't even realize that is what dmesg did. Here is the output I got: [ 2117.571792] bone_capemgr bone_capemgr: part_number 'PRU-GPIO-BLINK', version 'N/A' [ 2117.571876] bone_capemgr bone_capemgr: slot #10: override [ 2117.571920] bone_capemgr bone_capemgr:

Re: [beagleboard] Re: Beaglebone Black PRU Troubles

On Fri, Nov 11, 2016 at 12:42 PM, Zach B wrote: > I wanted to add on to this that when I switch the Device Tree Blob file > extension to ".dtbo" instead of ".dtb" I get the error: > -bash: echo: write error: File exists > instead of the file not found error I was getting

[beagleboard] Re: Beaglebone Black PRU Troubles

I wanted to add on to this that when I switch the Device Tree Blob file extension to ".dtbo" instead of ".dtb" I get the error: -bash: echo: write error: File exists instead of the file not found error I was getting previously. On Friday, November 11, 2016 at 1:27:22 PM UTC-5, Zach B wrote: > >

[beagleboard] Re: Beaglebone Black PRU Troubles

Hi everyone, So I messed around with my beaglebone a little bit last night. I worked out the issues in my device tree source file so it is now compiled but I can't seem to get anything to echo properly to "slots" I compile my ".dtb" file but when I go to call the comman: echo PRU-GPIO-BLINK >

[beagleboard] Re: Beaglebone Black PRU Troubles

Once you get everything solid, please take a look at dmesg after boot. I'm curious to see if you get successful PRU firmware start-up. Greg On Thursday, November 10, 2016 at 8:28:23 AM UTC-5, Zach B wrote: > > Hey everyone, I wanted to give an update. I got the remote_proc to turn on > last

[beagleboard] Re: Beaglebone Black PRU Troubles

Hey everyone, I wanted to give an update. I got the remote_proc to turn on last night. It was as simple as updating my repo like Robert had mentioned. I also made the correction that Brett mentioned about the pins. There is still something wrong in my device overlay file that is causing an

[beagleboard] Re: Beaglebone Black PRU Troubles

I think your device tree overlay is not quite right, I see P8.11 set as mode 6 with internal pull down, but you've set exclusive use on P8.12. I usually use http://kilobaser.com/blog/2014-07-28-beaglebone-black-devicetreeoverlay-generator to look up pinmux settings because it's easier and

Re: [beagleboard] Re: Beaglebone Black PRU Troubles

The problem is common to both boards, one with kernel a few months old, and another newer one: Older: 4.4.12-ti-r31 Newer: 4.4.27-ti-r62 The older board I have used for many hours of experimentation with the Remoteproc/PRUs, and never had a problem. I never noticed the firmwares were not

Re: [beagleboard] Re: Beaglebone Black PRU Troubles

On Tue, Nov 8, 2016 at 11:08 AM, Greg wrote: > I think I know exactly what is wrong. You need to activate the Remoteproc > PRU framework. This is no longer active by default. > Robert Nelson's script which is available via Github repository will fix > the problem. > >

[beagleboard] Re: Beaglebone Black PRU Troubles

I think I know exactly what is wrong. You need to activate the Remoteproc PRU framework. This is no longer active by default. Robert Nelson's script which is available via Github repository will fix the problem. I have been working on detailed documentation of the entire process to activate