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]> 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].
> 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/CAJhqRVF%2BnVTHuB4wLYHk7Zd8%2Bw8CmXQRMTrmxDpi87NhP4Lk2A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to