• State Accepted Answer
  • Locked Locked
  • Replies 3 replies
  • Subscribers 348 subscribers
  • Views 5100 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Why Cortex-R5 Bus-ECC documentation different from Cortex-R7

Pashan None

Hello Support,

In the Cortex-R5 TRM [Section 9.1.1 -- Bus ECC -- Chapter is  Level Two Interface] I see the following statement:

"

It is possible that fatal, that is double-bit, ECC errors

might cause more data corruption. This can result in the CPU operating on corrupted data, or

behaving unpredictably, based on corrupted control or response signals.

"

In the Cortex-R7 TRM [Section 11.1 -- About L2 Interface] I am unable to find anything similar to above related to Bus ECC,

Can you please help me understand whether Bus ECC within Cortex-R7 implementation doesn't have that limitation as Cortex-R5 for AXI Level 2 Master Interface?

Thank you.

Regards

Pashan

Parents
  • 0

    Hi pashan,

    I think both Cortex-R5 and R7 L2 memory interface have the same ECC secheme.
    They are SECDED (i.e. Single Error Correcton, Double Errors Detection).
    In the Cortex-R7 TRM [Section 7.2.4 ECC on external AXI bus], there are the following descriptions.

    • For single-bit errors, an inline correction is provided. A primary error detection
    notification output signal is raised at the same time. The inline correction implies some
    extra cycles of memory latency.
    Inline correction is not done on the TCM AXI slave port.


    • Double-bit errors only raise a primary error detection notification output signal. The
    system must determine the correct action in this case, such as an interrupt to the processor.

    Best regards,
    Yasuhiko Koumoto.

Reply
  • 0

    Hi pashan,

    I think both Cortex-R5 and R7 L2 memory interface have the same ECC secheme.
    They are SECDED (i.e. Single Error Correcton, Double Errors Detection).
    In the Cortex-R7 TRM [Section 7.2.4 ECC on external AXI bus], there are the following descriptions.

    • For single-bit errors, an inline correction is provided. A primary error detection
    notification output signal is raised at the same time. The inline correction implies some
    extra cycles of memory latency.
    Inline correction is not done on the TCM AXI slave port.


    • Double-bit errors only raise a primary error detection notification output signal. The
    system must determine the correct action in this case, such as an interrupt to the processor.

    Best regards,
    Yasuhiko Koumoto.

Children
  • 0 in reply to Yasuhiko Koumoto

    Hello Yasuhi,

    Thank you for informing the section on Corte-R7 for AXI Master Port ECC feature.

    Now the question is whether in case of Double Bit Error, Cortex-R5 doesn't guarantee the exact data as read from the AXI Slave will be available in the CPU as mentioned in the original post [Cortex-R5 TRM -- Section 9.1.1].
    Does Cortex-R7 gurantee that in case of Double Bit ECC Error on AXI Master Port, CPU will get the exact data as read from the AXI Slave device?

    Let me know how to find out that information from ARM TRM.

    Thank you.

    Regards

    Pashan

  • 0 in reply to Pashan None

    Hi Pashan,

    It would be a difficult matter.

    As for the ECC, and as for my case,  I will search the word 'correction' in the TRM.

    We can find the following descriptions

    The processor uses Single Error Correction and Double Error Detection (SEC-DED) ECCs to detect and correct errors in the RAMs and on the AXI buses. A finite number of hard, that is, permanent errors can be detected and corrected with continued operation using dedicated error registers.

    Furthermore, we can find the section "7.2 RAM protection" for more information with regard to the error correction.

    As the results, in the case of Cortex-R7, with more than one bit errors, the processor would not be deadlock or fallen into the fatal states because the erroneous cache line would be ignored (after retrying some times).

    Best regards,

    Yasuhiko Koumoto.