Part Number: MSPM0G3507
Hi TI team,
I am using MSPM0G3507 and would like to implement a RAM ECC self-test similar to the Renesas MCU ECC diagnostic flow.
On Renesas MCU, the self-test can intentionally create real SRAM ECC errors by using ECC bypass / test write mode:
1. Write normal data to SRAM.
2. Disable ECC check or enable ECC bypass/test mode.
3. Modify 1 bit or 2 bits of the SRAM data without updating the ECC syndrome.
4. Re-enable ECC check.
5. Read the SRAM address to trigger the ECC decoder.
6. Verify that 1-bit correctable error or 2-bit uncorrectable error is detected.
For MSPM0G3507, I found the following SYSCTL status/software-set events:
- SRAMSEC
- SRAMDED
- SYSCTL_ISET_SRAMSEC_MASK
- SYSCTL_NMIISET_SRAMDED_MASK
- SYSCTL_NMIIIDX_STAT_SRAMDED
I can use these registers to force the SRAMSEC/SRAMDED event path, but this only verifies the event/NMI handling path. It does not create a real SRAM data/ECC syndrome mismatch.
My question is:
Does MSPM0G3507 support any official method to inject real SRAM ECC/parity faults for diagnostic self-test?
Specifically:
1. Is there an ECC bypass mode, ECC test mode, or syndrome write mode for SRAM?
2. Can firmware intentionally create a 1-bit correctable SRAM ECC error?
3. Can firmware intentionally create a 2-bit uncorrectable SRAM ECC error and trigger SRAMDED/NMI?
4. If real SRAM ECC fault injection is not supported, is using SYSCTL_ISET_SRAMSEC_MASK and SYSCTL_NMIISET_SRAMDED_MASK the recommended way to verify the ECC event handling path?
SDK version: MSPM0 SDK 2.10.00.04
Diagnostic library version: mspm0_diag_lib_1_00_00_15
Toolchain: IAR Embedded Workbench for Arm 9.50.2
Thank you.
