SK-AM64: SK-AM64

Hello Shruti,

PRU has permissions to access memory outside of the PRU_ICSSG, including reading and writing to DDR memory.

For an example of using PRU to read and write to local memory, reference https://software-dl.ti.com/processor-sdk-linux/esd/AM64X/08_05_00_21/exports/docs/common/PRU-ICSS/PRU-Getting-Started-Labs_Lab5.html#debugging-the-pru-from-linux-core . Hopefully that gives you some pointers for things to think about with writing to memory from the PRU's viewpoint, and the A53 core's viewpoint.

I am not sure from your previous thread if read/write latencies to and from DDR matter to you. If they do, this FAQ may be helpful: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1096933/faq-pru-how-do-i-calculate-read-and-write-latencies/4065864#4065864

Regards,

Nick

Thanks Nick, will check these references , is there any example code in sdk related to the above mentioned topic , or any part in TRM where this thing is mentioned?

Thanks for the help

Hi Nick

so, I was trying to write some data from the reg file to the ddr memory, but it seems that the data is not being written in the memory, means the changes does not get reflected in the memory browser. I found about the pru ocp master port access thing in a thread in the forum, as of now i am not doing any changes in that ocp cfg register, could it be b'coz of that? is there any reference where I can get the significance of this ocp like what it is doing exactly?

Hello Shruti,

Which PRU devices need to change a setting to access memory outside of the PRU subsystem?

The older PRU-ICSS devices (AM335x, AM437x, AM57x) have to enable the OCP master ports in order to access memory regions outside of the PRU-ICSS. You can find an example of enabling the OCP master port by setting the SYSCFG register, STANDBY_INIT bit in the PRU Software Support Package (PSSP) RPMsg examples (e.g., https://git.ti.com/cgit/pru-software-support-package/pru-software-support-package/tree/examples/am335x/PRU_RPMsg_Echo_Interrupt0/main.c )

However, PRU_ICSSG devices (AM24x, AM64x, AM65x) do NOT have to change any settings to be able to access memory outside of the PRU subsystem. You will notice that the RPMsg examples in the PSSP for PRU_ICSSG devices do not have any OCP setting. E.g., https://git.ti.com/cgit/pru-software-support-package/pru-software-support-package/tree/examples/am64x/PRU_RPMsg_Echo_Interrupt0/main.c

The other PRU devices (AM263x, AM62x) also do NOT have to change any settings to be able to access memory outside of the PRU subsystem. Again, reference the RPMsg examples in PSSP: https://git.ti.com/cgit/pru-software-support-package/pru-software-support-package/tree/examples/am62x/PRU_RPMsg_Echo_Interrupt0/main.c

Regards,

Nick

So OCP settings are not your problem.

1) Have you first verified that you can write to memory inside of the PRU_ICSSG, and read the written values from somewhere else? Please follow the exact steps in Lab 5 of the PRU getting started labs: https://software-dl.ti.com/processor-sdk-linux/esd/AM64X/08_05_00_21/exports/docs/common/PRU-ICSS/PRU-Getting-Started-Labs_Lab5.html#debugging-the-pru-from-linux-core 

(as an aside, I have been assuming that you have some experience with PRU programming. If you have never programmed a PRU before, I suggest going through the entire PRU Getting Started Labs just to make sure you have a good foundation).

2) If you are still running into issues, please attach the PRU firmware code snippet where you are setting the values, and show screenshots or terminal output of where you are trying to read the memory value.

Regards,

Nick

Sure, will do this and let you know.

thanks for the suggestions...

Hi Nick,

I tried to run few codes to check whether we can access the memory or not, I am attaching the snippet of the codes that I was testing. it is basically the load and store instructions, the results I am verifying from the memory browser view and the register values from there the internal memory I was able to access and it was showing the expected values in both the memory browser window and the register data, but when I tried to use the same instructions with the external memory, I could not see the expected results in both memory browser and the register view. (Here the external memory I am referring to is the ddr memory)

also, I did notice that when I connected the r5f code without loaded any dmsc and pru firmware, I was able to access the memory browser like i was able to write the data from there, but as soon as i connected the dmsc and loaded the firmware, things got screwed up, and I was not able to access the memory browser.

the reference you shared earlier for pru getting started lab, there it is mentioned that the assembly code project does not read or modify values in memory also the assembly code project does not read or modify variables. does that mean we cannot use the memory browser for verifying the data in pru assembly code?  

Hello Shruti,

I am used to running these tests from a Linux context. I am not sure what behavior to expect from DDR access when CCS and R5F are the ones initializing DDR.

I am reassigning your thread to Anshu so that he can get someone more familiar with MCU+ SDK to take a look.

Regards,

Nick

Okay Thanks

Shruti,

I guess you are already working with ashwani on this thread. Lets bring the discussion to the forum.

Regards

Anshu