AM3358: PRU constant table entry McASP0 DMA

I am running Linux on the ARM side. McASP0 is not being used by the ARM core. Since the McASP REV register is read only shouldn't the PRU read the correct value regardless of ARM core activity?

Hello Andrew,

Here's what I've found so far:
It looks like the LBCO assembly instruction allows for an offset from an immediate value <256 OR from a register.

The first generation of PRU programmers I talked to only used immediate values <256 for the offset from the CREGISTER address, so any register set that was longer than 0x100 (like McASP0_DMA) was just listed as len=0x100 in the linker command file.

The next generation of programmers went through and changed the linker command file len values to the actual length of the register set - that's why your linker command file has CREGISTER entries like PRU_IEP len=0x31C. It looks like they just forgot to give MCASP0_DMA its actual length.

So what's the difference between len<=0x100 and len>0x100? I was told in your line
volatile far uint8_t CT_MCASP0 __attribute__((cregister("MCASP0_DMA", near), peripheral));
the second argument passed into cregister should be "near" if len<=0x100, and "far" if len>0x100. You can see this difference in pru-icss-5.1.0/include/am335x/pru_ecap.h and pru_iep.h. At the bottom of the file, pru_ecap.h uses near, while pru_iep uses far.

I have not been able to test the compiler's behavior quite yet, so I'm not sure what the PRU C compiler does with "near" vs "far" - e.g., toggle between LBCO and a different instruction, toggle between an immediate value offset and a offset stored in a register, etc. I'm also not sure what happens if your C code tries to access a register location with an offset of greater than 0x100, but the declaration is near, with len=0x100.

Regards,
Nick

Nick,

Thank you for the detailed response. Based on your reply I attempted a little experiment.

Modify the linker to:

MCASP0_DMA : org = 0x46000000 len = 0x000001010 CREGISTER=8

Define the following in my source code:

volatile far uint8_t CT_MCASP0 __attribute__((cregister("MCASP0_DMA", far), peripheral));
#define RBUF_OFFSET (0x280 / 4)
#define MCASP0_CT_RBUF (*(((volatile uint32_t *) &CT_MCASP0) + RBUF_OFFSET))

I then assign some variable to equal MCASP0_CT_RBUF. Looking at the assembly generated by the compiler I see:

LDI32     r0, ||CT_MCASP0||     ; [ALU_PRU] |723| CT_MCASP0
LDI       r1.w0, 0x0280         ; [ALU_PRU] |723|
LBBO      &r14, r0, r1.w0, 4    ; [ALU_PRU] |723|

Based on that I am thinking the constant table might be a no go for McASP0 when using the pru-cgt. I am sure you could inline some assembly if you absolutely needed it. For my application the cycle count difference isn't going to matter. Thanks again Nick. I do appreciate your help in understanding what I was seeing.

This is working for me. Thanks Nick!

Just as a follow up. I wasn't seeing this earlier, but once I started integrating the rest of my code I now get the following compiler error:

| "pru-mcasp.c", line 206: error #17003-D: relocation from function "mcasp_read"
|    to symbol "CT_MCASP0_DMA" overflowed; the 10-bit relocated address 0x280 is
|    too large to encode in the 8-bit unsigned field (type =
|    'R_PRU_FRDSO_U8_C32_So16s8_P0XFFFFFFFF' (17), file = "gen/pru-mcasp.object",
|    offset = 0x00000008, section = ".text:mcasp_read")

I am guessing this error is the result of the compiler trying to use LBCO with an immediate 8-bit value instead of a register offset.

I have the linker set as follows:

MCASP0_DMA		: org = 0x46000000 len = 0x00001010	CREGISTER=8

Constant table access to RBUF_0 is setup like this:

typedef struct {
	uint32_t rsvd[160];
	union {
		volatile uint32_t RBUF_0;
	};	// 0x280
} McASP0;

volatile __far McASP0 CT_MCASP0_DMA __attribute__((cregister("MCASP0_DMA", near), peripheral));

The only oddity I can think of is that I had to disable optimization on some functions as the compiler was reordering writes to volatile memory locations. It kind of wrecked my McASP initialization sequence. I thought reordering memory access was frowned on but it may be perfectly legal. I'm not up on all of the standards. Regardless I am using a few of the following pragma statements to get around reordered register writes.

#pragma FUNCTION_OPTIONS (function_name, "--opt_level=0")

I don't think this is causing the error though as I get the same behavior when these statements are commented out.

I had a chance to play around with this a little more. I can reliably reproduce the error when compiling multiple source files and CT_MCASP0_DMA is used in the file that does not contain main(). The error does not appear when using CT_MCASP0_DMA in the file that contains main().

Sorry to keep adding to this thread. But I was looking at the post I marked as the solution again. Isn't the generated assembly from your test case 2 still wrong?

According to the PRU Assembly Instruction User Guide, LBCO uses either an 8-bit immediate count or a 16-bit register count. Using format 1 with an immediate count should be invalid since 0x280 > 0xFF. This is essentially what the compiler produced for your test case 2. This is also the instruction produced in my code that the linker is complaining about.

LBCO      &r2, c8, 0x280, 4

To use the constant table with an offset greater than 0xff but less than 0x10000 I would expect the compiler to use the LBCO instruction format 2 which uses a register count.

LDI       r1.w0, 0x0280
LBCO      &r2, c8, r1.w0, 4

This should still be faster than the code generated by your test case 1.

LDI32     r0, ||CT_MCASP0_DMA|| ; [ALU_PRU] |117| $O$C1,CT_MCASP0_DMA
LBBO      &r1, r0, 0, 4         ; [ALU_PRU] |117| $O$C1
LDI       r1.w0, 0x0280         ; [ALU_PRU] |118| 
LBBO      &r0, r0, r1.w0, 4     ; [ALU_PRU] |118| $O$C1

Hello Andrew,

Thank you for keeping us updated! I suppose one part of the puzzle is that I'm not sure what $CSBREL() is doing in my generated code (if it is results in an immediate value rather than the value in a register, I would certainly expect it to give errors during compile time).

LBCO      &r0, __PRU_CREG_MCASP0_DMA, $CSBREL(||CT_MCASP0_DMA||+640), 4

I have passed your debug notes on to the compiler team. I will let you know when I learn anything knew.

Regards, 

Nick