Regarding RAM double bit ECC error handling

cancel
Showing results for 
Search instead for 
Did you mean: 

Regarding RAM double bit ECC error handling

472 Views
Contributor V

Hi,

I am using S12ZVMC128 MCU.

How to handle machine exception raised by RAM double bit ECC.

We learned that MCU reset is the correct recovery action but is there any other way to perform software reset other than COP ?. If not, can we enable only RAM single bit ECC ?

8 Replies

11 Views
NXP Employee
NXP Employee

Hi Pratibha,

The MCU reset is recommended way how to leave machine exception.

If MCU reset is not suitable for you, you may simply apply some jump to some code (e.g. to the Startup()) at end of machine exception instead of MCU reset.

 

The COP is the typical way how to reset MCU.

As an optional way, you may use some unused GPIO pin and connect it to the RESET pin externally. When you change pin direction to the output state with low level, it will reset MCU and pin reverts to the input state.

 

Unfortunately, the invoking machine exception upon double bit ECC error cannot be disabled.

I hope it helps you.

 

Have a great day,
Radek

 

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos

11 Views
Contributor V

Hi,

Thank you reply and support.

In Debug mode, When using "asm NOP" then iam able to reach Machine Exception ISR and able to Handle the ISR 

but Iam not sure whether same thing is happening in Stand-Alone Mode(i.e Without Debugger). Because iam not able to See operations i have defined in Machine Exception ISR getting reflected.

Please guide on how to make sure that machine exception is reached in StandAlone also.

RAM ECC_Double_Bit_Code.JPG

0 Kudos

11 Views
NXP Employee
NXP Employee

Hi Pratibha,

I suppose that by Stand-Alone Mode you mean Normal mode (how it is defined in RM).

 

This example code for testing ECC on RAM may be tested only in the special mode (with a connected debugger). The reason is that ECCDCMD register may be written just in the special mode.

I think, that this is logical – you should be able to cause ECC issue for debugging purpose, but not in normal condition when MCU runs in a target environment. Keeping such option available also in normal mode is too dangerous.

I hope it helps you.

Have a great day,
Radek

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

11 Views
Contributor II

Hi Radek,

I have integrated the sample code provided in S12ZVC192-RAM_ECC-CW106 to test double bit RAM ECC errors.

However, I am not able to successfully test the functionality.

Looks like ECCDCMD register is not being written.

The step which says "rawData should read 0x5AA5" actually reads 0x5AA0.

Any ideas on what I could be missing?

ECC.PNG

#include "mcuECC.h"
#include "mm9z1j638/mm9z1j638.h"

// variables for test
volatile unsigned int test_field @ 0x2800 = 0x0000;
volatile unsigned int resultData, resultECC, rawData, rawECC = 0;

void SRAMSingleBitECCInterruptEnable(void)
{
// Single bit MCU SRAM ECC error interrupt enable
ECCIE_SBEEIE = 1;
}

void testSRAMDoubleBitECCError(void)
{
test_field = 0x5AA5;

ECCDPTRH = 0x00;
ECCDPTRM = 0x28;
ECCDPTRL = 0x00;

//generating double bit ECC error by Debug pointer
ECCDD = 0x5AA0; //write data value with single bit ECC error
ECCDE = 0x39; //write incorrect ECC value
ECCDCMD = 0x82; //write to ECCDPTR address and disable Read Repair Function

ECCDCMD = 0x81; //read from ECCDPTR address with disabled Read Repair Function
rawData = ECCDD; //read data value at address 0x3000. It should be 0x5AA5
rawECC = ECCDE; //read ECC value at address 0x3000. It should be 0x39

resultData=test_field; //The reading will set ECC error flag and trigger ECC interrupt.
asm NOP; //just for debugging purpose - the step here will cause a jump to interrupt routine
}

0 Kudos

11 Views
NXP Employee
NXP Employee

Hi Mihir,

you are right. There is a typo error in this comment. Thank you for notification. I will fix the example code.

It is obvious. We rewrote original 0x5AA5 value by the newer 0x5AA0 value. After that, we read it when Read Repair Function is disabled. So, we must read the new 0x5AA0 value.

Anyway, the double bit ECC error cannot be automatically fixed by the Read Repair Function. 

I hope it helps you.

Best Regards

Radek

11 Views
Contributor II

Yes, I think the comments are incorrect for double bit error.

I was actually trying to understand why this piece of code wasn't resulting in a double bit ECC error.

The code just functions as usual. I was expecting to see a machine exception.

Looks like write to ECCDCMD register is not effective. There is a note in MM9Z1 datasheet saying that ECCDCMD register can only be written in special mode. I have no idea how to enter the special mode.

0 Kudos

11 Views
NXP Employee
NXP Employee

Hi Mihir,

Yes, that is correct. The ECCDCMD commands work only in a special mode for debugging purposes.

Therefore, the example code may be used only for simulating double bit ECC error, but not for invoking these errors in normal mode.

 

Anyway, the ECC check happened when we read from RAM/Flash/EEPROM. The ECCDCMD=0x81; is an exception from this statement. It will read data from RAM but without an ECC check. The ECC interrupt or machine exception occurs one clock after true RAM read, like command resultData = test_field;  

 

The difference in modes:

Normal mode – we connect the power and MCU starts executing code from Flash. In short: produced devices in the field.

Special mode – we connect the power supply and BDM debugger. The debugger SW resets MCU into a special mode and MCU waits for commands from debugger SW (like step-in, run, …). In short: when we debug application (in an ideal case, before production start).

 

For more details, please check chapter 5.2.6.1 Chip configuration modes on page 53 of MM9Z1_638 RM.


I hope it helps you.

Have a great day,
Radek

11 Views
Contributor II

Thanks, Radek. I was able to successfully trigger single and double bit ECC errors on RAM.

Your explanation about special mode was helpful.

0 Kudos