MPC5644A ECC error injection

[kaifalkenberg]

Hi,

I have a problem with testing SRAM ECC in the MPC5644A. I'm using ECSM.EEGR.FR1NCI to generate a single 2-bit data inversion. This seems to work so far, as ECSM.ESR.RNCE is being set. Also, I have set ECM.ECR.ERNCR to enable non-correctable error handling.

What does not work is that an interrupt for vector number 9 (page 355 in the reference manual) is triggered. I have an ISR assigned in my interrupt vector table and assigned INTC.PSR[9].B.PRI   = 0x06U;

What am I missing? Any hints are highly appreciated.

Thank you very much
Kai

[petervlna]

Hello,

Hmm, to me it looks like you SW is reset, as your MSR is cleared.

And you are not in interrupt handler IVOR4 (where the EE is cleared)

Check the RGM DES and FES registers after the step where you see the MSR cleared.

If there is any sign of reset.

Best regards,

Peter

[kaifalkenberg]

Hi,

I'm not sure what you mean by those registers. They don't seem to exist in the 5644A and neither in the core.

Here is a screenshot from SIU.RSR. It doesn't change over the critical single step:

kaifalkenberg_0-1727188829821.png

ERS always reads 1.

[petervlna · Accepted solution]

Hello,

Ok, so I was talking with colleague more experienced with this old device ECCs.

First is called IVOR1 on the error injection. As it have higher priority.

Only after it is called IVOR4 if enabled.

Please have a look at AN5200, you can use example for MPC5643L as they have identical ECSM and error handling.

https://www.nxp.com/docs/en/application-note/AN5200.pdf

http://www.nxp.com/files/microcontrollers/doc/app_note/AN5200SW.zip

Best regards,

Peter

[kaifalkenberg]

Hey Peter,

thank you so much! AN5200 chapter 3.2 was the missing link for me. In the end my IVOR1 handler wasn't correctly implemented.

[petervlna]

Hello,

There are only few things to check.

1. once your ECSM_ESR[FNCE] or ECSM_ESR[RNCE] is set,

2. and IRQ is enabled

petervlna_2-1725952538349.png

petervlna_1-1725952480107.png

Once you have correctly set ECSM you will trigger interrupt on INTC.

you can use simple read of INTC [IACKR] register via debugger which will show you the interrupt vector number.

If you can see correct vector (no.9) you know the ECSM reporting is set correctly.

Next you need to set priority for vector 9 and also ISR for it.

Best regards,

Peter

[kaifalkenberg]

Hi Peter,

thank you for your reply. I think I'm already doing what you mentioned. I'm also taking into account that most ECSM registers can only be written with a 32bit write operation.

kaifalkenberg_0-1725960416520.png

Here are two screenshots right before executing the read operation that should cause the error:

kaifalkenberg_1-1725960501265.pngkaifalkenberg_2-1725960517916.png

As you can see, ECR has ERNCR set and FR1NCI has been set. The instruction pointer is at 0x466D0. Once I single step again I get:

kaifalkenberg_3-1725960721694.png

but the IP is now completely off, eventually crashing the software:

kaifalkenberg_5-1725960802686.png

I do not see vector number 9 in IACKR after this operation.

[petervlna]

Hello,

Hmm, and do you have EE (external interrupts) enabled in the MSR core register?

petervlna_0-1726036486527.png

because I see your REAR holds address of ram 40000030 which is probably the address where you inject the ECC fault. This seems to me correct.

I do not see any other reason why the interrupts are not taken as clearly the ECSM is sending the signal to the INTC on RNCE=1 event.

petervlna_1-1726036584324.png

best regards,

Peter

[kaifalkenberg]

Hi Peter,

EE is set, so is ME and I have an IVOR1 handler registered. This is the situation at the breakpoint:

kaifalkenberg_0-1726037972922.png

kaifalkenberg_1-1726037986518.png

A single step further:

kaifalkenberg_2-1726038037357.pngkaifalkenberg_3-1726038063411.png

I think you are right and this issue is something outside of the ECSM.

[petervlna]

Hello,

What bothers me is that you do not have interrupt registered in IACKR.

I do not see vector number 9 in IACKR after this operation.

one you inject the fault, does your device end up at least in IVOR4 handler?

Is any other interrupt successfully called in your code?

Could you try one of our example code to see how the interrupt is processed?

https://community.nxp.com/t5/MPC5xxx-Knowledge-Base/MPC5-software-example-list/ta-p/1102445#MPC5644A

Best regards,

Peter

[kaifalkenberg]

Hi Peter,

first of all, thank you for your assistance!

Interrupt handling worked well so far. I have numerous interrupt handlers and they all work as expected.

No, after the single step right after the breakpoint (see above) I do not end up in my IVOR4 external interrupt handler!

What's bothering me is, that MSR is completely cleared once I do the single step:

kaifalkenberg_0-1726133896577.png

Is that to be expected?

Here is the MSR right before the single step:

kaifalkenberg_1-1726133981866.png