3.4.1. Overview of PRU-ICSS and PRU_ICSSG¶

3.4.1.10.1.1. What is the difference between the PRU subsystem and ICSS?¶

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.

3.4.1.10.1.2. Is TI providing libraries for the PRU?¶

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 SDK Documentation.

One exception is the ICSS firmware supported with the ICE and IDK boards.

3.4.1.10.1.3. Can I develop my own industrial protocols on the PRU-ICSS?¶

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.

3.4.1.10.1.4. Can the PRU run a High Level Operating System?¶

No, the PRU cannot run a HLOS such as Linux or Android.

3.4.1.10.1.5. My processor has a PRU. Is the PRU supported in the Linux Processor SDK?¶

It depends. OMAP138 PRU is NOT supported in Processor SDKs, and there are no plans to add support for it. However, the latest Processor SDKs support general purpose PRU development for AM335x/AMIC110, AM437x/AMIC120, AM57x, AM243x, AM64x, AM65x, and 66AK2G02 (K2G). More processors will be added in future releases.

3.4.1.10.2.1. 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].

3.4.1.10.2.2. In AM437x, why can PRU-ICSS0 not access memories outside of the ARM?¶

Make sure PRU-ICSS1’s OCP master port is enabled. PRU-ICSS0 accesses all external memories through the PRU-ICSS1 OCP master port.

3.4.1.10.2.3. Why can the PRU not edit pinmux settings?¶

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.

3.4.1.10.3.1. What is the maximum speed for toggling PRU GPO pins via PRU software?¶

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.

3.4.1.10.3.2. When does the PRU start capturing from the input pins?¶

The PRU continually captures and shifts the input once the GPI mode is set to 28-bit shift mode.

3.4.1.10.3.3. Can the module be modified so that the GPI start bit is a zero instead of a one?¶

No, the GPI start bit flag only detects the first 1 captured.

3.4.1.10.3.4. What happens after 28 bit GPI shifts?¶

The shift register overflows into a bit bucket.

3.4.1.10.3.5. 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<n>_LOAD_GPO_SH0/1. Note for AM335x, PRU<n>_LOAD_GPO_SH0/1 corresponds to pru<n>_r30[29/30]. Please refer to the technical reference manuals for other devices to confirm how PRU<n>_LOAD_GPO_SH0/1 is mapped.

3.4.1.10.3.6. When does PRU<n>_CLOCKOUT start running?¶

PRU<n>_CLOCKOUT is a free-running clock that begins when the PRU GPO mode is set to shift out mode. It is independent of PRU<n>_ENABLE_SHIFT.

3.4.1.10.3.7. When does the PRU start shifting data in the shadow registers?¶

The PRU starts shifting data as soon as the PRU<n>_ENABLE_SHIFT bit is set, regardless of the configured GPO mode. The output on PRU<n>_DATAOUT would only be seen if in shift out mode, but the shadow registers would still “drain” when in other GPO modes.

3.4.1.10.3.8. The shadow registers are loaded by writing to PRU<n>_R30 [0:15]. Does this change the state of the corresponding device-level pins?¶

If any device-level pins mapped to PRU<n>_R30 [2:15] are configured for the PRU<n>_R30 [2:15] pinmux setting, then yes, these pins will reflect the value written to PRU<n>_R30. Any pin configured for a different pinmux setting will not reflect the value written to PRU<n>_R30.

3.4.1.10.3.9. When the PRU<n>_ENABLE_SHIFT bit is cleared, does the PRU immediately stop shifting PRU<n>_DATAOUT?¶

No, when the shift operation is disabled by clearing the PRU<n>_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]).

3.4.1.10.3.10. Does the PRU shift data out LSB or MSB first?¶

The PRU shifts data out LSB first. PRU<n>_R30[0] = SH0/1[0] = LSB = first bit to be shifted out.

3.4.1.10.3.11. 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.

3.4.1.10.4.1. How can a PRU core interrupt the ARM? How can the ARM interrupt a PRU core?¶

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.

3.4.1.10.4.2. On devices with multiple PRU-ICSSs, how can one PRU-ICSS interrupt the other?¶

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.

3.4.1.10.5.1. 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.

3.4.1.10.5.2. 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.