• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 3 answers
  • Subscribers 31 subscribers
  • Views 347 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM2612: PRU-ICSS self-test and error signaling

Hideaki Matsumoto
Genius 9785 points

Part Number: AM2612

Hi,
 
We have received two questions from the customer regarding the safety features of the PRU. Could you help to answer their questions below ?
  1. Self-Test Coverage: Regarding memory-related self-test features (PBIST, LBIST, and ECC), are these also applicable to the PRU-ICSS ?
  2. Error Signaling: If an error occurs within the PRU-ICSS, is it possible to output that error via the ESM (Error Signaling Module)?

Thanks and regards,
Hideaki

  • 0
    TI__Guru 59390 points

    Hi Hideki-San,

    Let me get back with this info by today.

  • 0 in reply to Nilabh Anand
    TI__Guru 59390 points

    Please find the response attached:

    1. Self-Test Coverage (PBIST, LBIST, ECC) for PRU-ICSS

    Feature
    Applicable to PRU-ICSS?
    Details
    PBIST
    White check mark Yes
    Supported on all local PRU-ICSS memories [1]
    ECC
    White check mark Yes
    SECDED ECC on all PRU-ICSS memories [1]
    LBIST
    No
    No LBIST coverage for PRU-ICSS [1]

    PBIST is supported on all local memories within the PRU-ICSS subsystem [1]. The PRU-ICSS is classified as a FuSa-Lite sub-system on the AM2612 [1].

    ECC (SECDED — Single Error Correction, Double Error Detection) is implemented across all PRU-ICSS memories [1], specifically covering the following memory structures via an integrated ECC Aggregator module [2]:

    • Data RAM0 (8 KB)
    • Data RAM1 (8 KB)
    • PRU0 Instruction Memory (16 KB)
    • PRU1 Instruction Memory (16 KB)
    • Shared Data RAM2 (32 KB)

    LBIST coverage does not extend to the PRU-ICSS [1].

    2. Error Signaling via ESM

    Yes — PRU-ICSS errors are routed to the ESM, and the ESM can signal those errors externally. The AM2612 documentation explicitly states that errors within the PRU-ICSS are reported to the device ESM [1], with specific channel assignments defined as follows [1]:

    Error Type
    ESM Group
    ESM Channel
    Correctable ECC errors (ICSSG0 RAMs)
    Group 1
    Channel 40
    Uncorrectable ECC errors (ICSSG0 RAMs)
    Group 1
    Channel 41
    Timeout errors (OCP master port, PRU/RTU_PRU) + IEP parity errors
    Group 1
    Channel 42

    The ESM aggregates safety-related events from across the SoC and can generate interrupts to processing cores while asserting the external SAFETY_ERRORn pin (active LOW when PWM mode is disabled) [4]. This pin can be monitored by an external safety controller or system supervisor to take appropriate action upon fault detection [4].

    ECC single-bit (SEC) and double-bit (DED) error pulse interrupts are output to the ESM [2], meaning both correctable and uncorrectable memory faults within the PRU-ICSS are covered by this signaling path.

    To summarize: PBIST and ECC are confirmed for PRU-ICSS; LBIST is not documented as applicable. All PRU-ICSS ECC errors are routed to the ESM with defined channel assignments and can be signaled externally via the SAFETY_ERROR pin. 

    Citations

    1. AM2612 Datasheet (SPRSPA7C)
    2. AM2612 Technical Reference Manual (SPRUJB6B)
    3. E2E Forum – AM2612 Diagnostics Example Codes
    4. AM2612 Datasheet (SPRSPA7C) – SAFETY_ERRORn Pin
  • 0 in reply to Nilabh Anand
    TI__Genius 9785 points

    Hi Nilabh,

    Thank you for your answers. OK, understood that LBIST coverage does not extend to the PRU-ICSS.

    How does the self test perform for PRU logic ? By software ? If so, is there any example for PRU-ICSS ? I can't find it.

    Thanks and regards,

    Hideaki

  • 0 in reply to Hideaki Matsumoto
    TI__Guru 59390 points
    Hideaki Matsumoto said:
    How does the self test perform for PRU logic ? By software ? If so, is there any example for PRU-ICSS ? I can't find it.

    PBIST is performed by Software, like any other memory, ,please refer to the SDL example here - https://software-dl.ti.com/mcu-plus-sdk/esd/AM261X/11_01_00_19/exports/docs/api_guide_am261x/SDL_PBIST_PAGE.html

    PRU memeory are also included.

  • 0 in reply to Nilabh Anand
    TI__Genius 9785 points

    Hi Nilabh,

    I'm not sure, but I think LBIST is used for CPUs, Logics, gates, etc.. I found the SDL examples for R5F subsystem. Can these SDL libraries be used for each logic module on PRU-ICSS ? 

    Thanks and regards,

    Hideaki

  • 0 in reply to Hideaki Matsumoto
    TI__Guru 59390 points
    Hideaki Matsumoto said:
    I'm not sure, but I think LBIST is used for CPUs, Logics, gates, etc.. I found the SDL examples for R5F subsystem. Can these SDL libraries be used for each logic module on PRU-ICSS ? 

    Hi Hideki,

    I need to confirm again with HW architect, but it looks like STC does not cover PRU cores.

    STC is responsible for LBIST for R5F cores

  • 0 in reply to Nilabh Anand
    TI__Genius 9785 points

    Hi Nilabh,

    Thank you for confirming with HW architect. Please let us know once you got any feedback from them.

    Thanks and regards,

    Hideaki

  • 0 in reply to Hideaki Matsumoto
    TI__Guru 59390 points

    Hi Hideaki-San,

    Got confirmation from the HW side as well, we do not have LBIST for PRU. 

  • 0 in reply to Nilabh Anand
    TI__Genius 9785 points

    Hi Nilabh,

    I understood no LBIST for PRU. You mentioned as follows.

    Nilabh Anand said:

    PBIST is performed by Software, like any other memory, ,please refer to the SDL example here - https://software-dl.ti.com/mcu-plus-sdk/esd/AM261X/11_01_00_19/exports/docs/api_guide_am261x/SDL_PBIST_PAGE.html

    PRU memeory are also included.

     

    I've responded below.

    Hideaki Matsumoto said:
    I'm not sure, but I think LBIST is used for CPUs, Logics, gates, etc.. I found the SDL examples for R5F subsystem. Can these SDL libraries be used for each logic module on PRU-ICSS ? 

     

    The customer needs anything to perform self-test for cores, logics and gates on PRU-ICSS.

    Thanks and regards,

    Hideaki

  • 0 in reply to Hideaki Matsumoto
    TI__Guru 59390 points

    Hi Hideki-San

    LBIST itself is implemnted by HW, And if you ask is it possible to do sw based lbist then

    The short answer is no, you cannot write a pure software test case to perform a true LBIST (Logic Built-In Self-Test) for the PRU-ICSS logic and CPU.

    ​However, you can achieve similar safety and diagnostic goals using Software-Based Self-Tests (SBST). Here is the breakdown of why LBIST is restricted and how you can implement a software alternative.

    ​1. Why LBIST cannot be "Written" in Software

    ​LBIST is a hardware-based structural test. It uses a BIST controller and Scan Chains (flip-flops connected in a long shift register) to toggle logic gates at the hardware level.

    ​Hardware Dependency: LBIST requires specific hardware hooks to isolate the logic from the rest of the system, apply pseudo-random patterns, and observe the output signature.

    ​Destructive Nature: LBIST is usually destructive to the CPU state. If the STC (Self-Test Controller) on the AM261x does not have the PRU-ICSS in its scan partition, software cannot "force" the hardware to perform a scan test.

    ​Access: Logic gates inside the PRU-ICSS that are not memory-mapped or accessible via the instruction set cannot be toggled or verified by software.

    ​2. The Alternative: Software-Based Self-Test (SBST)

    ​Since you cannot trigger the hardware LBIST, you must use the PRU's own instruction set to verify its "health." This is a common approach in functional safety (e.g., SIL2/SIL3) when hardware BIST is unavailable.

    ​For the PRU CPU

    ​You can write a firmware routine that executes a series of tests to verify the integrity of the execution unit:

    ​Register File Test: Write patterns (like 0x55555555 and 0xAAAAAAAA) to all PRU registers (r0 through r31) and read them back to ensure no bits are stuck.

    ​ALU Functional Test: Perform a battery of operations (ADD, SUB, XOR, LSL) with known inputs and verify that the results match expected values.

    ​Instruction Integrity: Execute rare or complex instructions (like SBCO/LBCO for constant table access) to ensure the decoding logic is functional.

    ​For the PRU-ICSS Logic (Peripherals/Flow)

    ​To test the "Logic" surrounding the PRU (the ICSS fabric):

    ​Memory ECC/Parity: Manually trigger or check the parity/ECC logic for the PRU Data RAM and Instruction RAM.

    ​Interrupt Controller (INTC) Test: Use the software-interrupt trigger bit to ensure the INTC can correctly route an event from the PRU to the R5F or to another PRU.

    ​Loopback Tests: If using the PRU for industrial protocols (like EtherCAT or PROFINET), implement a digital loopback at the MII/RGMII level to verify the frame processing logic.

  • +1 in reply to Nilabh Anand
    TI__Guru 59390 points

    This logic customer can implement themselves, if this approach works for tgem