AM62x - SK - EVM: How to acess physical adress of the PRU registers with c baremetal coding?

Hi! Thanks for the atention.

Tha value stored on R2 at line 17 breakpoint is 0x0F8

Hello Rafael,

Just triple checking: it has been a couple of years since I looked into this, but back in the day I needed to add another set of parentheses to the memory location in order to read and write to it. Could you try doing it based on this example in the getting started labs and let us know if you are able to modify the memory address?

https://git.ti.com/cgit/pru-software-support-package/pru-software-support-package/tree/labs/Getting_Started_Labs/c_code/solution/am62x/main.c

(companion code for https://software-dl.ti.com/processor-sdk-linux/esd/AM62X/09_01_00_08/exports/docs/common/PRU-ICSS/PRU-Getting-Started-Labs_Lab2_cCode.html )

Regards,

Nick

Hello! Thank you for your attention!

In the case of my video code, I removed the last parentheses and the pointer because the variable was already declared pointing, so this syntax was unusable.

Even so, I've already tested it by directly accessing the defines with the address (*(volatile uint32_t)(0x30066008)) and it gave the same thing.

Now, with other tests, I read the memory by taking the contents of the address that I write to a variable, so I can see what I wrote to the variable, but even so, in the memory map it remains zero.

Hi Rafael,

I performed a small test on my end.

If you connect to any of the R5F cores and search the register address in the memory browser, you can see that the register value is updated.

I tried this test on AM64x on my end as in the attached screenshots below:

AM64x GPCFG0 register:

PRU code:

Memory browser and Register view from R5F core:

I will look into the cause of this inconsistency in CCS memory browser view. 

Meanwhile, can you check the same on your end and let me know the results: Write the register using PRU and check the register location from R5F core.

Regards,

Nitika