AM437x PRU-ICSS RAM memory type

Jacek Jaworski

Other Parts Discussed in Thread: SYSBIOS

Hi,

I use idkam437x with ccs 6.1.2 and sysbios 2.1.1.2.

In some sdk project examples (like motor_control), many variables are kept in PRU1 RAM memory of PRUICSS0 module, by the following declaration:

variable1 = (float*) (((PRUICSS_HwAttrs *)(PRUICSS_handle->hwAttrs))->baseAddr + DATA_OFFSET );

This is to provide access to these variables by PRU units so everything seems absolutely legit.

But I would like to ask about the drawbacks of that action. I mean, if there is any additional delay when reading/writing a value into the PRU RAM memory - comparing to 'typical' area, i.e. by typical variable declaration, such as:

float variable2;

BTW. In which memory area will the variable2 be kept?

Thank you in advance!

over 9 years ago

0 Biser Gatchev-XID over 9 years ago

TI__Guru**** 393215 points

I will ask the RTOS team to comment.

0 David Zaucha over 9 years ago in reply to Biser Gatchev-XID

TI__Expert 7570 points

Hi

PRU memory access to local memory are much faster than PRU access to L3 memory. The PRU individual writes to L3 memory are buffered. However PRU reads to L3 memory are direct, so that the timing is influenced by other activity on the bus. In comparison, PRU access to local memory are not affected by ARM read/writes to the PRU memory. The PRU shared memory is typically were ARM and PRU communication occur.

David

0 Jacek Jaworski over 9 years ago in reply to David Zaucha

Expert 1325 points

Hi David
Thanks for your answer.
I am more concerned how these actions influence the Cortex efficiency as my code written to share lots of variables between ARM and PRU is really inefficient....
I must limit the number of variables kept in PRUs' shared memory as it slowes down the Cortex, right?

Second question concerns Cortex memory: Variables declared in a traditional way seem to be located in DDR memory (the address starts with 0x800xxx). Can I force them to be located in other memory area which is quicker to write/read?

Thanks!
JJ

0 David Zaucha over 9 years ago in reply to Jacek Jaworski

TI__Expert 7570 points

Hi JJ

ARM writing to PRU memory is perhaps 50% slower than writing to L3 OCMC memory when caching is disabled. So it is reasonably quick.

There was a recent E2E post on allocating data in PRU memory https://e2e.ti.com/support/embedded/starterware/f/790/p/524358/1915622#1915622

David

0 Jacek Jaworski over 9 years ago in reply to David Zaucha

Expert 1325 points

Hi David,

Thanks for the answer and the link.

So if a variable is not important for PRU work, there is absolutely no need to put it in PRU memory.

How much does the caching help? Is the ARM's access to cached PRU memory comparable to standard access to L3OCMC memory?

As I see, all my variables are automatically located over the address 0x800xxx - so I suppose the compiler choose the DDR memory for them. Should I force them to be located in L3OCMC memory as my project is directed towards high sampling frequency of the control system?

Thank you in advance,

0 David Zaucha over 9 years ago in reply to Jacek Jaworski

TI__Expert 7570 points

Hi JJ

After initialization the ARM should only store and/or read values in PRU memory that need to be exchanged with the PRU. We configure ARM access to PRU memory as not cached and shared as shown in the referenced e2e discussion above that used the Sigma Delta Decimation Filter (SDDF) Guide Client example for illustration (in C:\ti\sysbios_ind_sdk_2.1.1.2\sdk\examples\sddf_gui_client)

{(void *)0x54400000, 0 /*SYS_MMU_SHAREABLE | SYS_MMU_BUFFERABLE*/}, //PRU-ICSS0/1 -Bufferable| Non Cacheable | Shareable

The cached performance of the AM437 DDR memory is excellent. We use this configuration in our examples because in most cases its performance is tough to improve upon.

David

0 Jacek Jaworski over 9 years ago in reply to David Zaucha

Expert 1325 points

Hi David,

Ok - that's more clear now.

Thank you,

Processors

Processors forum

AM437x PRU-ICSS RAM memory type