AM6442: Not finding PRU0_CTRL, declared it instead. How to improve?

Nelson Castillo

Part Number: AM6442

Hi!

First post here. Having fun with PRUs.

Using the most recent support package from git.

I couldn't find the symbol PRU0_CTRL while extending the SPAD example for a test (PRU0->PRU1). Thus build fails when I include it.

PRU0_CTRL is defined in AM64x_PRU0_intc.cmd and I included:

#include <pru_cfg.h>
#include <pru_ctrl.h>
#include <pru_intc.h>

I could access the register with this declaration and it worked great, I could measure a delay.

volatile __far ctrl *PRU0_CTRL = (volatile ctrl*)0x00022000;

But I see that other registers that I see in examples are not working and I wonder what I'm doing wrong.

For instance, this line doesn't work, the symbol is not present thus the build fails in this line.

CT_CFG.SYSCFG_bit.STANDBY_INIT = 0;

Does it ring a bell?

over 1 year ago

0 Bin Liu over 1 year ago

TI__Guru**** 167551 points

Hi Nelson,

Our PRU expert is out of office until the end of October. Please expect delayed response.

+1 Nick Saulnier over 1 year ago

TI__Guru** 100740 points

Hello Nelson,

Just got back. Hopefully the PRU development has continued to be fun over the past 3 weeks!

1) by "git", I assume you are referencing the PRU Software Support Package? (PSSP)
https://git.ti.com/cgit/pru-software-support-package/pru-software-support-package/

If so, which version of the PSSP are you using? Please note that we have recently added additional AM24x / AM64x examples that have not yet been tagged with a version number: https://git.ti.com/cgit/pru-software-support-package/pru-software-support-package/log/

2) Which example are you trying to run where you are seeing issues? Please note that the PRU's internal register map for older devices like AM335x is a bit different than the register map for the AM64x, so the linker command files and the associated header files where we define registers will put some register groups in different places, and call some register groups by different names.

3) If you have not seen all the PRU documentation hiding in the Linux Processor SDK, please take a look:
https://software-dl.ti.com/processor-sdk-linux/esd/AM64X/09_00_00_03/exports/docs/linux/Foundational_Components_PRU_Subsystem.html

If you are a true PRU beginner I would suggest starting with the PRU Getting Started Labs: https://software-dl.ti.com/processor-sdk-linux/esd/AM64X/09_00_00_03/exports/docs/common/PRU-ICSS/PRU-Getting-Started-Labs.html

You might also be interested in some of the other pages, like a description of the header files you are using here: https://software-dl.ti.com/processor-sdk-linux/esd/AM64X/09_00_00_03/exports/docs/common/PRU-ICSS/Header_Files.html

Regards,

Nick

0 Nelson Castillo over 1 year ago in reply to Nick Saulnier

Prodigy 145 points

Thanks Nick!

I see that my issue was not finding the field inside the declared register. I thought I had trouble finding the actual registers. Thanks for your pointers, they were helpful.

I have two related questions:

1) I'm using the cycle counter to measure intervals. Would something like the am437x/PRU_IEP be good for this use case? It would be nice to have a timer example for am64x.

2) I'm using the registers at 0x00a90008 and 0x00a9000C for time-stamping, they have already been set to 200Mhz so I am relying on this. Is it fast to access those from the PRU? Another way to ask: Do they use the shared bus or are routed in some other way?

0 Nick Saulnier over 1 year ago in reply to Nelson Castillo

TI__Guru** 100740 points

Hello Nelson,

measuring clock cycles

the PRU_CYCLE register is fine for measuring intervals of time that are less than a (32 bit number) of PRU clock cycles. IEP timer could be helpful if you are measuring periods of time that could be longer.

I do not have immediate plans for updating the IEP timer example for AM64x, but the concepts should be very similar. If you have specific questions, you can ask them.

accessing registers

Are you accessing... the GTC counter value registers?
GTC_CNTCV_LO
GTC_CNTCV_HI

What exactly are you trying to do here?

If you are just doing something like write the PRU_CYCLE register values that you read, it would make more sense to just write to the PRU's local Data RAM. In general, I would not use the GTC to timestamp events in the PRU_ICSSG - use the IEP timer or the PRU_CYCLE counter instead.

If you are trying to synchronize the PRU's counter with a counter somewhere else, like the Linux system time, then that is a more complex discussion. You can see a starting discussion at https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1252399/faq-how-to-synchronize-the-pru-iep-timer-with-linux-system-time

Are you trying to adjust the PRU core clock frequencies?

If so, please take a look at these FAQs:
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1041347/faq-pru_icssg-how-to-check-and-set-pru-core-frequency-in-ccs
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1049800/faq-pru_icssg-how-to-check-and-set-pru-core-frequency-in-linux

Other fun reading

Since I've already pointed you to half the links in this FAQ, let me just send it in case there is anything else helpful you might find:
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1204069/faq-sitara-multicore-development-and-documentation/4540835#4540835

Regards,

Nick

0 Nelson Castillo over 1 year ago in reply to Nick Saulnier

Prodigy 145 points

Nick Saulnier said:
Are you accessing... the GTC counter value registers?
GTC_CNTCV_LO
GTC_CNTCV_HI

What exactly are you trying to do here?

If you are just doing something like write the PRU_CYCLE register values that you read, it would make more sense to just write to the PRU's local Data RAM. In general, I would not use the GTC to timestamp events in the PRU_ICSSG - use the IEP timer or the PRU_CYCLE counter instead.

Hello there. Yes, GTC registers. I'm reading data from an ADC. I want to timestamp the reads and make the values make sense in Linux as well, even if not synced to a system clock.

At this stage I think I'm trying to use the GTC registers, as if the PRU had a 64-bit cycle counter. And also good that it's available in other cores.

Not trying to link to a wall-clock time yet.

The PTP link is useful. I will need to dig into that soon for a better implementation.

+1 Nick Saulnier over 1 year ago in reply to Nelson Castillo

TI__Guru** 100740 points

For GTC access, just keep in mind that it will take some number of nanoseconds to access the GTC time. If your system can handle microseconds or milliseconds of difference between Linux's understanding of the ADC timestamp and the PRU's understanding of the ADC timestamp though, you should be fine.

For more discussion on PRU core read & write latencies, see https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1096933/faq-pru-how-do-i-calculate-read-and-write-latencies

Regards,

Nick

Processors

Processors forum

AM6442: Not finding PRU0_CTRL, declared it instead. How to improve?