Pruss Question Re PRU_memAcc_DDR_sharedRAM.p

GoogleGroups
1

I am having difficulty understanding a short snippet of code from the PRU_memAcc_DDR_sharedRAM.p example. The code is:

// Configure the programmable pointer register for PRU0 by setting c31_pointer[15:0]
// field to 0x0010. This will make C31 point to 0x80001000 (DDR memory).
MOV r0, 0x00100000
MOV r1, CTPPR_1
ST32 r0, r1

The comment states the field is being set to 0x0010 yet the immediate value being programmed into
r0 is 0x00100000 not 0x0010. I can not understand why this sets the pointer to 0x80001000 rather than
0x8010000. Are there any pruss programmers that could shed some light on my misunderstanding here?
The example does work and does give an offset 0x1000 bytes in the DDR memory, so there is something I’m
missing. Thanks in advance.
Bit_Pusher

2

Just follow through the PRU reference guide.

Section 5.4.9 CTPPR1 Register
The value is being written to CTPPR1, which controls the pointers for
entries 30 and 31 in the constant table. The 0x00100000 value written
breaks down as:

Bits 31-16 = 0x0010 = C31 Pointer value
Bits 15-00 = 0x0000 = C30 Pointer value

Section 5.2.1 Constant Table
The 0x0010 C31 pointer value gets combined with the constant table value
to form the actual address:

0x80nn_nn00, nnnn = c31_pointer[15:0]

So since the C31 pointer from CTPPR1 is 0x0010, the resulting address is:

0x80nn_nn00 with nnnn=0x0010 or 0x8000_1000

Easy-peasy!

3

Thanks Charles this helps, I didn’t realize a single address location is used to modify two constants. I’m slowly working my way through the documentation, but there’s a lot of it without many examples I’ve found to date and the examples supplied didn’t really explain what was going on. On a separate issue, do you know of any examples that use the debug registers? Finally, 5.4.7 has a typo (SPRUHF8A– May 2012 –Revised June 2013 it states it modifies entries 24 and 25 in the PRU Constant Table where it should be entries 26 and 27 - it’s a pretty obvious typo though so it shouldn’t cause problems)

4

There are a few PRU debugging tools that access the debug registers
which might be enough of an example for you.

I made a list of these a while back:

http://blog.machinekit.io/2013/06/beagle-bone-pru-links.html

I know the PRU debugger in Machinekit will let you single-step and read
register values. That's all I've needed to use so-far...maybe by now
some of the other projects are farther along.

NOTE: The current home of the Machinekit PRU code is:

https://github.com/machinekit/machinekit/tree/master/configs/pru-examples

5

Thanks Charles, I was actually hoping to find something that explains what the PRU debug registers in section 5.5 of the reference manual:
5.5 PRU_ICSS_PRU_DEBUG Registers
are for, and how to use them.
Bit_Pusher

6

Well, the reference manual tells you what they're for, and how to use
them is an exercise left to the reader. :wink:

Basically you are provided with the tools to halt and single-step the
PRU, as well as access some internal state (like the register contents),
with some of the data only available if the PRU is halted.

If you have specific questions about the registers, ask. You'll
generally the more specific your questions the better the answers you'll
get.