MPC5643L non correctable SRAM errors observability

[stefanodimasci1]

In this kind of the device a non correctable error causes a reset. I'd like to know by software and send to the outside world (using the UART) what happened and where. The problem is that after the reset , as the main start, every information is lost in ESR. When should I record the information to let the software know that the reset was caused by a non correctable error in SRAM?

[stefanodimasci1]

If I access a SRAM or flash location with a non correctable error in such way:

value=*((uint32_t *)0x40000000)

will it be recorded in the core without ECSM reporting?

Thank you

[davidtosenovjan]

Yes, it'll be.

[stefanodimasci1]

Ok,

but the problem now is: how can i check if my handling is correct If I can inject a fault just with ECSM reporting enabled?

Thank you very much

[davidtosenovjan]

I have described the topic in section 7 in following document. You can find in here:

AN5200 - Error Correcting Codes Implemented on MPC55xx and MPC56xx

[stefanodimasci1]

Thank you very much, I've already read that.

But the problem is: after the reset ESR is set to all 0s,so I can't access ECC registers to know what happened (that would cause an error), even if I know from RGM that an ECC error happened. I don't see how can I have information about the problem in this way

[davidtosenovjan · Accepted solution]

Yes, that’s right. I have mentioned it in chapter 7.1 §3

You can keep ESCM reporting disabled. In this case multi-bit ECC error device is not reset and you can handle ECC error in IVOR1 exception (see chapter 5.1) but such approach does not catch ECC errors from other masters than the core.

It is such specialty of MPC5643L device.