LS1028A / Cortex-A72: Is software L1/L2 cache ECC error injection supported?

[philz12]

I need to confirm whether L1/L2 cache ECC can be tested by injection.

From the Cortex-A72 TRM I understand:

- L1D and L2 provide ECC

- Errors are reported via CPUMERRSR_EL1 / L2MERRSR_EL1

- I have not found any software-accessible way to inject ECC errors into the A72 L1D or L2 cache arrays

Questions:

1) Does LS1028A (or the A72 implementation on this part) provide any software-accessible way to inject ECC errors into L1D/L2?

2) If injection is not supported, what does NXP recommend for verifying L1/L2 ECC detect/correct behavior in a power-on BIT context?

[Bio_TICFSL]

Hello,

Q1: Does LS1028A / Cortex-A72 Support Software ECC Error Injection into L1D/L2?

No — the Cortex-A72 does not support software-accessible ECC error injection for L1 or L2 cache.

Q2: NXP-Recommended Alternatives for Power-On BIT Verification of L1/L2 ECC

Since injection is not available on the A72, NXP's position is that direct ECC error injection testing of L1/L2 is not feasible in software on this core, and customers requiring this level of BIT coverage should consider the following approaches:

1. Verify ECC Reporting Path via CPUMERRSR_EL1 / L2MERRSR_EL1

2. Consult ARM Directly for Any Undocumented Debug Hooks

3. Rely on ARM's Architectural Validation (Design-Level Assurance)

For safety-critical applications, the standard industry approach when injection is not available is to rely on ARM's own silicon validation and the architectural guarantee that SECDED ECC is implemented. The LS1028A datasheet confirms "Parity and ECC protected 32 KB L1 instruction and 32 KB L1 data cache" and "1 MB L2 cache with ECC protection."ARM's silicon qualification process covers ECC correctness at the IP level.

4. Consider Migration to a Newer Core for Full BIT Coverage

If software-injectable ECC BIT is a hard requirement (e.g., for IEC 61508 / DO-254 compliance), NXP's newer Cortex-A55–based SoCs (e.g., i.MX 93) provide dedicated ECC Error Injection registers (e.g., CODE_CACHE_TAG0_ECC_ERROR_INJEC, SYSTEM_CACHE_DATA0_ECC_ERROR_INJEC) that are explicitly designed for verification and debugging. The A72 → A55/A78AE migration path is something NXP actively supports.

Regards