TMS570LC4357: Writing directly to ECC memory to create 1-bit and 2-bit error in the L2RAMW

Hi Deric,

We have safeTI diagnostic library code, which consists of code for injecting different faults in the controller. You can download it from below link:

SAFETI_DIAG_LIB Driver or library | TI.com

Once you download safeTI diagnostic library, now you can refer the code related to the SRAM_ECC_ERROR_FORCING_1BIT and SRAM_ECC_ERROR_FORCING_2BIT

Here they gave the code for creating single bit(correctable error ) and double bit (uncorrectable errors) for RAM.

So please follow the code given in safeTI diagnostic library.

And you can also refer my first comment in the below thread, where i explained the process they are doing in safeTI diagnostic library for SRAM_ECC_ERROR_FORCING_1BIT and SRAM_ECC_ERROR_FORCING_2BIT.

(+) RM57L843: How to inject ESM_G2ERR_L2RAMW_UNCORR_B/ESM_G1ERR_L2RAMW_CORRERR respectively and trigger ESM interrupt - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

--

Thanks & regards,
Jagadish.

Hi Jaga

Thanks. Previously I have managed to use the safeTI library to create the 1 or 2 bit ECC errors that will trigger the ESM 2.7 L2RAMW Uncorrectable Error Type B. But now my intention is to manually write to the RAM and its ECC to cause the ESM3.3 L2RAMW double bit ECC uncorrectable Error. 

Any ideas to share with me.

Hi Deric,

Deric Ng said:

But now my intention is to manually write to the RAM and its ECC to cause the ESM3.3 L2RAMW double bit ECC uncorrectable Error. 

Please use the code in the switch-case SRAM_ECC_ERROR_FORCING_2BIT in SDL as reference to create ESM3.3 and also explained what exactly the code doing in the below thread:

(+) RM57L843: How to inject ESM_G2ERR_L2RAMW_UNCORR_B/ESM_G1ERR_L2RAMW_CORRERR respectively and trigger ESM interrupt - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

--

Thanks & regards,
Jagadish.

Yes, i have tried above and cause the ESM2.7 to happen. In additon, i have changed/corrupt the ECC for the the global variable and would expect that the ESM3.3 to happen. But it does not, do you have any idea on this?

Hi Deric,

The ECC error injection (1-bit or 2-bit) in RAM test mode will not generate ESM3.3 error. It is generated when SECDED logic fails to correct 1-bit ECC error, or the redundant address decode generates an address error, or there is a 2-bit ECC error during read-modify-write operation. 

Good Morning QJ,

Thanks for the reply.

1) It is generated when SECDED logic fails to correct 1-bit ECC error,

2) the redundant address decode generates an address error,

3)  there is a 2-bit ECC error during read-modify-write operation. 

For these 3 scenarios, how can they be triggered? I have tried (3) by changing ECC_DETECT_EN=5h and ECC_WR_EN=0 to intentionally corrupt the ram variable and its ECC. That did not work out.

Do I miss out anything or that is not the proper way to do so. Hope to hear from you soon. Good day.

I have performed sub64 bit writes as outline in TRM 8.2.2.1 ECC handling 8,16 and 32 Writes.

Deric Ng said:

changing ECC_DETECT_EN=5h and ECC_WR_EN=0 to intentionally corrupt the ram variable and its ECC.

This is "Uncorrectable error Type B", ESM 2.7.

One way you can try: read the RAM after PBIST. The March13N algorithm initializes the memory array to a know pattern, then writes different patterns through the memory including RAM’s ECC space. After PBIST, the ECC space contains invalid ECC code, so reading RAM address will generate ECC error.

The E2E forum maintenance was down for maintenance yesterday and today, sorry for delayed response.