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 system should start reading or writing too. That appears to be true but it also appears to be directly tied to the banks. For example, when I was telling it to write &R21 data to bank0 it was writing to R21 in bank0 instead of the start of bank0 memory (R1). When I went to read the data back out I was attempting to write the data to &R1 on the PRU but that also means, as far as I understand, that it was reading directly from &R1 in bank0 when the data was actually in &R21 in bank0.
I could be wrong but my few tests with both c and assembly seem to show that's what was occuring. Zach On Monday, December 5, 2016 at 9:05:36 AM UTC-5, laurel.a.watts wrote: > > 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 <[email protected] <javascript:>> > wrote: > >> 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 out into a separate register and it >> doesn't appear to be working. I get nothing back out of bank0. Is there >> some control register that you have to set to activate these banks? >> Here is the code I am using to test >> init: >> LDI32 R21, 0x55555555 >> LDI32 R1, 0x00000000 >> LDI32 R2, 0x00000020 >> XOUT 10, &R21, 4 >> NOP >> XIN 10, &R1, 1 >> ; MOV R1, R21 >> >> SUB R2, R2, 1 >> MOV R30, R1 >> NOP >> >> read_loop: >> SUB R2, R2, 1 >> LSR R30, R30, 1 >> NOP >> QBNE read_loop, R2, 0 >> QBA init >> HALT >> >> >> The MOV command works just fine but the XIN command does nothing. The >> register remains empty. Any thoughts? >> >> >> Zach >> >> On Tuesday, November 29, 2016 at 10:16:37 AM UTC-5, Jason Reeder wrote: >>> >>> 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 hands >>> first. Let me know if you run into any issues. >>> >>> I was running on a recent-ish version of the Debian distro on my BBGW. >>> I'm fairly certain that I am seeing the same dmesg output that you are >>> reporting. I don't think it happens with our TI Processor SDK distro so I >>> haven't looked too closely at it yet. If I get a chance tonight after work >>> I'll try to update to the latest Debian and see if I can't root cause the >>> PRU boot loading issues. >>> >>> Jason Reeder >>> >>> >>> On Tuesday, November 29, 2016 at 6:25:34 AM UTC-6, Greg wrote: >>>> >>>> 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 recent Debian distribution on >>>> a Beaglebone. >>>> I was wondering if you see this in the dmesg log. This is for PRU0, >>>> and there is a repeated instance of these messages for PRU1. >>>> >>>> It's not a big deal as the firmwares can be started reliably after >>>> boot. I was not seeing this on the Beaglebones a few months ago, as the >>>> firmwares would be up and running automatically >>>> after boot. Just curious what is going on... >>>> >>>> [ 4.705647] irq: no irq domain found for >>>> /ocp/pruss@4a300000/intc@4a320000 ! >>>> [ 4.742790] irq: no irq domain found for >>>> /ocp/pruss@4a300000/intc@4a320000 ! >>>> [ 4.836176] remoteproc1: 4a334000.pru0 is available >>>> [ 4.836201] remoteproc1: Note: remoteproc is still under >>>> development and considered experimental. >>>> [ 4.836210] remoteproc1: THE BINARY FORMAT IS NOT YET FINALIZED, >>>> and backward compatibility isn't yet guaranteed. >>>> [ 4.836500] remoteproc1: Direct firmware load for am335x-pru0-fw >>>> failed with error -2 >>>> [ 4.836520] remoteproc1: failed to load am335x-pru0-fw >>>> [ 4.847402] pru-rproc 4a334000.pru0: booting the PRU core manually >>>> [ 4.847433] remoteproc1: powering up 4a334000.pru0 >>>> [ 4.847543] remoteproc1: Direct firmware load for am335x-pru0-fw >>>> failed with error -2 >>>> [ 4.847559] remoteproc1: request_firmware failed: -2 >>>> [ 4.852787] pru-rproc 4a334000.pru0: rproc_boot failed >>>> [ 4.969567] remoteproc1: releasing 4a334000.pru0 >>>> [ 4.969746] pru-rproc: probe of 4a334000.pru0 failed with error -2 >>>> >>>> >>>> On Monday, November 28, 2016 at 11:52:36 PM UTC-5, Jason Reeder wrote: >>>>> >>>>> 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 >>>>> assembly only projec >>>>> >>>>> -- >> For more options, visit http://beagleboard.org/discuss >> --- >> You received this message because you are subscribed to the Google Groups >> "BeagleBoard" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/beagleboard/77f4936f-70fa-49b5-b45b-8d6c38b3937e%40googlegroups.com >> >> <https://groups.google.com/d/msgid/beagleboard/77f4936f-70fa-49b5-b45b-8d6c38b3937e%40googlegroups.com?utm_medium=email&utm_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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/eaea3231-aaa1-44e4-9b5d-b89c076da975%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
