RM48L952: RAM ECC single bit error test fails if repeated

Giulia

Part Number: RM48L952
Other Parts Discussed in Thread: HALCOGEN

Hi,

I want to perform periodically a RAM ECC self-test in my application. I started from self-test functions generated by Halcogen in sys_selftest.c file. Since 2-bit error causes an abort, I need to remove the 2-bit error injection in the functions. I attach the two modified functions that I’m calling. There are two different results:

- If I call the checkRAMECC()_mod function periodically, everything is fine. Every time I inject 1-bit error, both tcram1ErrStat and tcram2ErrStat flags are set as expected.

- If I call the checkB0RAMECC()_mod function periodically, tcram1ErrStat is set just the first time I call the function. From the second time that I call the function, the flag is not set anymore as if the error is not corrected.

There is a reason for this behavior? How can I proceed?

Thanks

Fullscreen 8463.Functions.c Download

bool checkRAMECC_mod()
{
	bool error = false;
	volatile SIS_U64 ramread = 0U;
	volatile SIS_U32 regread = 0U;
	SIS_U32 tcram1ErrStat, tcram2ErrStat = 0U;

	SIS_U64 tcramA1_bk = tcramA1bit;
	SIS_U64 tcramB1_bk = tcramB1bit;

	/* Clear RAMOCUUR before setting RAMTHRESHOLD register */
	tcram1REG->RAMOCCUR = 0U;
	tcram2REG->RAMOCCUR = 0U;
	/* Set Single-bit Error Threshold Count as 1 */
	tcram1REG->RAMTHRESHOLD = 1U; 
	tcram2REG->RAMTHRESHOLD = 1U; 
	/* Disable single bit error generation */
	tcram1REG->RAMINTCTRL = 0U;
	tcram2REG->RAMINTCTRL = 0U;

	/* Enable writes to ECC Memory, enable ECC error response */
	tcram1REG->RAMCTRL = 0x0005010AU;
	tcram2REG->RAMCTRL = 0x0005010AU;       

	/* Force a single bit or double bit error in both the banks */
	/* corrupting RAM ECC 1-bit cause a corrected 1-bit ECC error and SERR flag set if threshold is 1 */
	_coreDisableRamEcc_();
	tcramA1bitError ^= 1U;
	tcramB1bitError ^= 1U;
	_coreEnableRamEcc_();

	/* Read the corrupted data to generate single bit error */
	ramread = tcramA1bit;
	ramread = tcramB1bit;
	

	/* Check for error status */
	tcram1ErrStat = tcram1REG->RAMERRSTATUS & mcECC_SERR_FLAG_MASK;
	tcram2ErrStat = tcram2REG->RAMERRSTATUS & mcECC_SERR_FLAG_MASK;
		  
	if ((tcram1ErrStat == 0U) || (tcram2ErrStat == 0U))	      // SERR not set in TCRAM1 or TCRAM2 modules
	{
		error = true;						                     // TCRAM module does not reflect 1-bit error reported by CPU
	}
	else
	{
	/* Clear SERR flag by writing 1, otherwise it stays set and an error is detected even if no error are present! */
		tcram1REG->RAMERRSTATUS = 0x1U;
		tcram2REG->RAMERRSTATUS = 0x1U;      
	}

	regread = tcram1REG->RAMUERRADDR;
	regread = tcram2REG->RAMUERRADDR;

	/* Restore backup value, disabling writes to ECC RAM */
	tcram1REG->RAMCTRL = 0x0005000AU;
	tcram2REG->RAMCTRL = 0x0005000AU;

	/* Compute correct ECC */
	tcramA1bit = tcramA1_bk;
	tcramB1bit = tcramB1_bk;
	tcramA2bit = tcramA2_bk;
	tcramB2bit = tcramB2_bk;
	
	return error;
}




bool checkB0RAMECC_mod()
{
	bool error = false;
	volatile SIS_U64 ramread = 0U;
	volatile SIS_U32 regread = 0U;
	SIS_U32 tcram1ErrStat, tcram2ErrStat = 0U;

	SIS_U64 tcramA1_bk = tcramA1bit;

	/* Clear RAMOCUUR before setting RAMTHRESHOLD register */
	tcram1REG->RAMOCCUR = 0U;
	tcram2REG->RAMOCCUR = 0U;
	/* Set Single-bit Error Threshold Count as 1 */
	tcram1REG->RAMTHRESHOLD = 1U; /* It must be set to 1 for a correct test, otherwise SERR flag will never set to 1 in this test*/
	tcram2REG->RAMTHRESHOLD = 1U; 
	/* Disable single bit error generation */
	tcram1REG->RAMINTCTRL = 0U;
	tcram2REG->RAMINTCTRL = 0U;

	/* Enable writes to ECC Memory, enable ECC error response */
	tcram1REG->RAMCTRL = 0x0005010AU;
	tcram2REG->RAMCTRL = 0x0005010AU;       

	/* Force a single bit or double bit error in both the banks */
	_coreDisableRamEcc_();
	tcramA1bitError ^= 1U;
	_coreEnableRamEcc_();

	/* Read the corrupted data to generate single bit error */
	ramread = tcramA1bit;

	/* Check for error status */
	tcram1ErrStat = tcram1REG->RAMERRSTATUS & mcECC_SERR_FLAG_MASK;
	tcram2ErrStat = tcram2REG->RAMERRSTATUS & mcECC_SERR_FLAG_MASK;

	if ((tcram1ErrStat == 0U) && (tcram2ErrStat == 0U))	      // SERR not set in TCRAM1 or TCRAM2 modules
	{
		error = true;					                     // TCRAM module does not reflect 1-bit error reported by CPU
	}
	else
	{
		/* Clear SERR flag by writing 1, otherwise it stays set and an error is detected even if no error are present! */
		tcram1REG->RAMERRSTATUS = 0x1U;
		tcram2REG->RAMERRSTATUS = 0x1U;      
	}

	regread = tcram1REG->RAMUERRADDR;
	regread = tcram2REG->RAMUERRADDR;

	/* Restore backup value, disabling writes to ECC RAM */
	tcram1REG->RAMCTRL = bkRAMCTRL1;
	tcram2REG->RAMCTRL = bkRAMCTRL2;

	/* Compute correct ECC */
	tcramA1bit = tcramA1_bk;
	
	return error;
}

over 6 years ago

0 QJ Wang over 6 years ago

TI__Guru**** 196526 points

Hello Smeet,

It is expected.

CPU will read from the cache instead of reading from the SRAM if the address is same. This cache is a special buffer designed for ECC, and it is not user visible.

The Cortex-R4 processor attempts to correct 1-bit errors in the SRAM by writing the corrected data back to the SRAM and retrying the access. If a 1-bit error is due to a hard fault, then doing this will not change the data read from the SRAM, and when the access is retried, the same error will be detected again and the processor will livelock, forever detecting the error and retrying and not making any progress.

The purpose of the hard error cache is to prevent CPU from reading the SRAM which has permanent single bit error. Let's say there is a defect in one of the memory cells. If you read from it the CPU will detect it as a single bit ECC error. What the CPU will try to do is to save the corrected data to the hard error cache and also write back the corrected to the SRAM and then retry. Next time if the CPU reads from the same error address then it simply read from the cache instead of reading from the SRAM since there is a match in the address.

You can do like this:
1. address 1: corrupt its ECC, read the data to get ESM error
2. address 2: corrupt its ECC, read the data to get ESM error
3. address 1 again: corrupt its ECC, read the data to get ESM error

0 Giulia over 6 years ago in reply to QJ Wang

Prodigy 150 points

Hello QJ Wang,

Thanks for the explanation. There is still something I do not understand about the mode of operation of the RM48 device's ECC. First, I want to ask if there is an official document where I can find all necessary information about this topic.

Based on your answer, I'm expecting such behavior (correct me if I'm wrong). Considering the checkB0RAMECC_mod function attached before, the steps are:

/* (1) Read from SRAM: during a memory read, the ECC bits in the ECC space are read along with the data to detect or correct any error. In this case there are no error to be detected because I have not forced a single bit error yet. */

SIS_U64 tcramA1_bk = tcramA1bit;

/* Configuration of tcram1REG and tcram2REG */

…

/* (2) Force a single bit error in ECC space */

tcramA1bitError ^= 1U;

/* (3) Read from SRAM: at this point an error must be detected because the ECC bits in the ECC space are different from the ECC generated for the current data read from tcramA1bit address of SRAM. */

ramread = tcramA1bit;

/* Check for error status */

…

/* (4) Restore the initial value at tcramA1bit address of SRAM : during this write operation the hardware generates the corresponding ECC check bits for the tcramA1_bk data and stores the value in the ECC space */

tcramA1bit = tcramA1_bk;

Question: which data is going to be corrected between point (3) and (4)? Is the data stored at tcramA1bit address of SRAM that is going to be changed accordingly to the new ECC bits written in (2)? How can I verify this value change?

Then, the second time I call this function, everything is the same except for point (3): the CPU read from cache the value that was corrected at previous call. This read value mismatches with the new ECC bits that have been changed again at (2) of the current call, but CPU will not correct the error because it is an hard error so the error status flag is not set. Am I right?

Thanks

0 QJ Wang over 6 years ago in reply to Giulia

TI__Guru**** 196526 points

Hello,

This RAM is protected by ECC allowing the CPU to correct any single-bit errors. If CPU reads from data from SRAM and detects an single bit ECC error, the data will be corrected based on the ECC value in ECC memory.

Your understanding is correct, but the data is correct since the corrected data is in the cache.

Using the following sequence to get the error every time:
1. address 1: corrupt its ECC, read the data to get ESM error
2. address 2: corrupt its ECC, read the data to get ESM error
3. address 1 again: corrupt its ECC, read the data to get ESM error

This sequence will generate 2nd erorr:

1. address 1: corrupt its ECC, read the data to get ESM error

2. address 1: corrupt its ECC, read the corrected data (from the cache), but don't get ESM error

3. address 1: corrupt its ECC, read the corrected data (from the cache), but don't get ESM error

0 Giulia over 6 years ago in reply to QJ Wang

Prodigy 150 points

Hello,

thanks for the reply. Just one more general clarification about RM48 ECC: is the corrected data ONLY in the cache?

What I mean is this: does processor correct 1-bit error by writing the corrected data ALSO back to the SRAM?

If this is the case, if I use the following sequence (not repeated!):

address 1: read the data from SRAM (called value 1)
address 1: corrupt its ECC
address 1: read the data from SRAM to get ESM error
reset error flag
address 1: read the data from SRAM (called value 2)

at point 5 should I read a value 2 different from value 1?

Thanks

0 Giulia over 6 years ago in reply to Giulia

Prodigy 150 points

Just to clarify, I always read 0 and no value changing.

0 Giulia over 6 years ago in reply to Giulia

Prodigy 150 points

Hello,

any clarification about the last posted topic?

Thanks

0 Valerio Zanella over 6 years ago in reply to Giulia

Intellectual 270 points

Hi QJ Wang,

The mechanism you mention "cache is a special buffer designed for ECC", is not documented. Looking into ARM technical reference seems that it is implemented into R7 architecture (http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0458c/BGBFGEFD.html) but not in R4. Is this the one you were referencing? Is it undocumented for R4? How deep is that cache?

We really need more details on RAM ECC to face questions and tests with our TUV assessors. RAM ECC is a fundamental safety mechanism.

We do not understand its behavior in many circumstances and it is difficult to implement systematic tests in these conditions.

For example explain the behavior of the following code, it is executed right at the end of initialization produced by HALcogen "_c_int00()". I just wanted to understand how RAM ECC was changed, but it seems not predictable.

Code just changes RAM content and reads corresponding ECC. According to documentation RAM ECC can be read always, even if ECC write is not enabled. Consider "_coreEnableRamEcc_()" has been called before.

3 things are strange (red in code comments)

The 8 bytes for a single ECC location are not equal within the same 64 bit (it should according to your documentation)
ECC doesn't change anymore after the first write to RAM
A data abort is raised if read is performed on a second location and then back on the first location

void triggerECCabort()
{
#define tcramAddress1 (0x08000010U)
#define tcram1Location (*(volatile uint64 *)(tcramAddress1))
#define tcram1EccLocation (*(volatile uint32 *)(tcramAddress1|0x0400000U))
#define tcramAddress2 (tcramAddress1+0x10)
#define tcram2Location (*(volatile uint64 *)(tcramAddress2))
#define tcram2EccLocation (*(volatile uint32 *)(tcramAddress2|0x0400000U))

volatile SIS_U32 ramEccread = 0U;

//DEBUG: All ram is zeroed and ECC memory is all 0x0C

/* Location 1: change value in RAM and view corresponding value in ECC RAM */
ramEccread = tcram1EccLocation; //ECC=0x0C0C0C0C
tcram1Location = 4U; // write in RAM something
ramEccread = tcram1EccLocation; //ECC changes to 0xDFDFDFDB, 1. why least significant byte is read differently?
tcram1Location = 312312U; // write in RAM something
ramEccread = tcram1EccLocation; //2. ECC does not change, why?

/* Location 2: change value in RAM and view corresponding value in ECC RAM */
ramEccread = tcram2EccLocation;
tcram2Location = 4U;
ramEccread = tcram2EccLocation;
tcram2Location = 312312U;
ramEccread = tcram2EccLocation;

/* Again Location 1: change value in RAM and view corresponding value in ECC RAM */
ramEccread = tcram1EccLocation; //3. This causes a data abort, from Fault Status Registers I see it is from source "Synchronous Parity or ECC Error". Why??
tcram1Location = 4U;
ramEccread = tcram1EccLocation;
tcram1Location = 312312U;
ramEccread = tcram1EccLocation;
}

Are we missing something?

Strangely if I disable ECC (_coreDisableRamEcc_) problems 1 and 2 disappear. Even 3 but I guess due to the missing ecc check.

Regards,

Valerio

0 QJ Wang over 6 years ago in reply to Valerio Zanella

TI__Guru**** 196526 points

Hi Valerio,

Will study your code.

0 QJ Wang over 6 years ago in reply to QJ Wang

TI__Guru**** 196526 points

Hello Valerio,

For every 64-bit write to the RAM, the CPU writes an 8-bit ECC to ECC space. For every 64-bit read from the RAM, an 8-bit ECC is read by the CPU on its ECC bus automatically. Only the first byte is valid.

I tried your code, and observed the same phenomena. I am investigating and come back to you later. Sorry for late response.

0 Valerio Zanella over 6 years ago in reply to QJ Wang

Intellectual 270 points

Hi QJ Wang,

any suggestion?

We are really under pressure about understanding ECC, poor documentation and confusing bahavior are not helping...

Thank you,

Valerio

0 QJ Wang over 5 years ago in reply to Valerio Zanella

TI__Guru**** 196526 points

Hi Valerio,

I haven't got chance to investigate this phenomenon. I am sorry for the delay.

0 Valerio Zanella over 5 years ago in reply to QJ Wang

Intellectual 270 points

QJ Wang,

do you have any predictions about when you will have that chance?

I do not exclude our mistake but I would expect a different kind of support on one of the main diagnostics of the micro.

Thanks,

Valerio

0 QJ Wang over 5 years ago in reply to Valerio Zanella

TI__Guru**** 196526 points

Hello Valerio,

ECC memory can be written or read by a master because it is memory mapped. During ECC read, the return ECC will be duplicated in all the bytes. For every 64-bit write to the RAM, the CPU also write an 8-bit ECC value using the ECC bus. But there is no ECC for ECC value. To avoid false single or double-bit errors, we need to disable the ECC check before reading ECC data.

When I did the test, I got data abort, and the abort status shows that the abort is caused by the ECC error.

Arm-based microcontrollers

Arm-based microcontrollers forum

RM48L952: RAM ECC single bit error test fails if repeated