1.3. PRU-ICSS FAQ¶
- PRU Applications & Support questions
- Q: What is the difference between the PRU subsystem and ICSS?
- Q: Is TI providing libraries for the PRU?
- Q: Can I develop my own industrial protocols on the PRU-ICSS?
- Q: What differences exist between the PRU-ICSS in difference devices?
- Q: Where can I find more information about the PRU?
- Q: Can the PRU run a High Level Operating System?
- Q: My processor has a PRU. Is the PRU supported in the Linux Processor SDK?
- PRU Memory Access questions
- PRU GPI/O questions
- PRU GPO direct output mode
- PRU GPI 28-bit shift in
- PRU GPO shift out
- Q: Can data be pre-loaded into shadow registers prior to configuring the PRU GPO mode to shift out mode?
- Q: When does PRU_CLOCKOUT start running?
- Q: When does the PRU start shifting data in the shadow registers?
- Q: The shadow registers are loaded by writing to PRU_R30 [0:15]. Does this change the state of the corresponding device-level pins?
- Q: When the PRU_ENABLE_SHIFT bit is cleared, does the PRU immediately stop shifting PRU_DATAOUT?
- Q: Does the PRU shift data out LSB or MSB first?
- Q: What happens to the content stored in R30 when the PRU changes to a different GPO mode?
- PRU INTC and System Event questions
- PRU Debugger questions
- PRU Linux Driver questions
This article serves as a compilation of Frequently Asked Questions regarding the PRU.
PRU subsystem and ICSS both refer to the same hardware (PRU-ICSS), but their distinction lies in the targeted applications. The term “PRU subsystem” is used for broad market (or non-industrial) applications, while the term “ICSS” is used for industrial applications. The ICSS is supported with ICE and IDK boards and Industrial Software Kit.
TI is not providing libraries for the PRU. Customers will need to develop their own PRU firmware. However, TI does provide the foundation for PRU development through example software and other resources available through the PRU-ICSS wiki page.
One exception is the ICSS firmware supported with the ICE and IDK boards.
TI only supports the industrial protocols enabled in the IDK (Industrial Development Kit) available on ti.com. Independent development of industrial protocols using the MII_RT and IEP (Industrial Ethernet Peripheral) blocks in not supported or enabled.
The PRU-ICSS differences between devices are summarized in the PRU-ICSS Feature Comparison wiki article.
No, the PRU cannot run a HLOS such as Linux or Android.
It depends. OMAP138 PRU is NOT supported in Linux Processor SDKs 4.3 and older, and there are no plans to add support for it. However, Linux Processor SDK 4.3 does support the PRU for AMIC11x, AM335x, AM437x, AM572x / AM571x, and 66AK2G02 (K2G). More processors will be added in future releases.
18.104.22.168. Q: Why does my PRU firmware hang when reading or writing to an address external to the PRU Subsystem?¶
The OCP master port is in standby and needs to be enabled in the PRU-ICSS CFG register space, SYSCFG[STANDBY_INIT].
Make sure PRU-ICSS1’s OCP master port is enabled. PRU-ICSS0 accesses all external memories through the PRU-ICSS1 OCP master port.
The PRU does not have privileges to edit the pinmux or pad config settings in the device-level Control Module. However, the PRU can read these registers.
The max PRU IO speed depends on the PRU software executing on the PRU and is therefore not published.
For example, if the PRU software contained a tight loop that only toggled a PRU GPO pin, then the fastest 50% duty cycle square wave we could achieve would be 50 MHz. This is based on a 4 instruction loop (1. SET output, 2. NOP, 3. CLEAR output, 4. LOOP back to Set instruction) with the PRU running at 200 MHz. However, if the PRU needed to do any processing in addition to toggling the GPO, then that max speed starts decreasing with the number of PRU instructions that are executed between the GPO toggles.
The PRU continually captures and shifts the input once the GPI mode is set to 28-bit shift mode.
No, the GPI start bit flag only detects the first 1 captured.
22.214.171.124.1. Q: Can data be pre-loaded into shadow registers prior to configuring the PRU GPO mode to shift out mode?¶
Yes, data can be loaded into the shadow registers even when the PRU is configured for a different GPO mode by setting PRU_LOAD_GPO_SH0/1. Note for AM335x, PRU_LOAD_GPO_SH0/1 corresponds to pru_r30[29/30]. Please refer to the technical reference manuals for other devices to confirm how PRU_LOAD_GPO_SH0/1 is mapped.
PRU_CLOCKOUT is a free-running clock that begins when the PRU GPO mode is set to shift out mode. It is independent of PRU_ENABLE_SHIFT.
The PRU starts shifting data as soon as the PRU_ENABLE_SHIFT bit is set, regardless of the configured GPO mode. The output on PRU_DATAOUT would only be seen if in shift out mode, but the shadow registers would still “drain” when in other GPO modes.
126.96.36.199.4. Q: The shadow registers are loaded by writing to PRU_R30 [0:15]. Does this change the state of the corresponding device-level pins?¶
If any device-level pins mapped to PRU_R30 [2:15] are configured for the PRU_R30 [2:15] pinmux setting, then yes, these pins will reflect the value written to PRU_R30. Any pin configured for a different pinmux setting will not reflect the value written to PRU_R30.
188.8.131.52.5. Q: When the PRU_ENABLE_SHIFT bit is cleared, does the PRU immediately stop shifting PRU_DATAOUT?¶
No, when the shift operation is disabled by clearing the PRU_ENABLE_SHIFT bit, the PRU will continue shifting all the data loaded in the shadow register used for GPO shifting (i.e. GPCFG0/1[PRU0/1_GPO_SH_SEL]).
The PRU shifts data out LSB first. PRU_R30 = SH0/1 = LSB = first bit to be shifted out.
184.108.40.206.7. Q: What happens to the content stored in R30 when the PRU changes to a different GPO mode?¶
R30 holds state when changing between GPO modes.
The PRU can interrupt the ARM by writing to R31 and generating a system event. The PRU INTC should be pre-configured to map this system event to a Host interrupt that is connected to the ARM (ie Host 2-9 on AM335x). The ARM can interrupt a PRU by writing to the PRU INTC SRSRx register and setting a pr<k>_pru_mst_intr<x>_intr_req system event. The PRU INTC should be pre-configured to map this system event to a Host interrupt that is connected to the PRU (ie Host 0-1 on AM335x). The PRU can poll R31 bit 30 or 31 to detect an interrupt on Host 0 or 1, respectively.
Check the PRU-ICSS System Event table in your device-specific reference manual on ti.com. There will be a System event tied to a PRU Host event from the other PRU-ICSS. By generating an interrupt of this Host, one PRU-ICSS can interrupt another PRU-ICSS. The other PRU-ICSS will detect this interrupt as the corresponding System event.
For example, on AM437x, the PRU can generate an interrupt on Host 7. The other PRU-ICSS will receive this as system event 56.
220.127.116.11. Q: When using the XDS510 USB emulator, why does the PRU Program Counter not increment correctly when stepping through PRU Disassembly code?¶
There is a known bug associated with PRU debug in the XDS510 USB class driver, and a different emulator should be used to debug the PRU. Two good alternatives are the XDS200 or the XDS560v2 emulators. Comparative benchmarks for various classes of XDS emulators are available at XDS_Performance_comparison.
18.104.22.168. Q: Why are no MMRs outside the PRU subsystem visible from the PRU perspective memory browser window in CCS?¶
The PRU core is capable of writing to the 32 bit memory map (i.e. MMRs outside of the PRU subsystem) but the PRU perspective of the CCS memory browser just cannot show those addresses. To view the full 32 bit memory map in a memory browser in CCS, the ARM core perspective or the DAP (debug access port) perspective should be used.
Note the PRU perspective memory browser includes a drop-down menu for viewing the following memories:
- Program_Memory - Instruction ram for the PRU
- Data_Memory - Data ram for the PRU
- PRU_Device_Memory - The memory map inside the PRU subsystem starting with the base address of the shared memory (0x00010000). Includes PRU shared memory and all submodules inside the PRU subsystem.
As a result of shared reset logic between the two PRU subsystems in the AM437x device, the current implementation of the Linux driver (pruss_remoteproc) can only load one subsystem (two PRUs) with firmware. Since subsystem 1 (PRUSS1) has larger instruction and data rams, as well as a shared ram, the decision was made to support it, instead of PRUSS0. Support for loading both subsystems simultaneously is planned for a future release of the Linux Processor SDK but that support is not currently there.