How to verify MPC5554 machine check exception handling?

[mikesfn]

Is there a simple way to inject a machine check exception in the MPC5554 (e200z6 core)? I need to test handling to understand the difference in behavior when the MSR[ME] bit is 0 instead of 1.

The e200z6 core manual provides the following definition for the MSR[ME] bit:

However, the MPC5554 provides 2 additional sources of machine check exception:

It's not clear to me how to simulate these conditions. What I need to know primarily is what will happen if the MSR[ME] bit is disabled? Will the conditions that normally cause the machine check exception to be taken all result in checkstop instead? Can anyone provide a simple example of code that results in a machine check condition?

[lukaszadrapa · Accepted solution]

Hi,

the easiest option is to access unimplemented area or inject double bit ECC error to flash or SRAM as described in AN5200:

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

https://www.nxp.com/docs/en/application-note-software/AN5200SW.zip

So, either read/write unimplemented area (or data corrupted by ECC error) or fetch an instruction from such area (simply jump there).

And this section from AN5200 could be useful:

Regards,

Lukas

[mikesfn]

Thanks. I tried out the test code in AN5200 and this results in a Data Storage exception (IVOR2) being taken, which would seem to confirm erratum e1143 for the MPC5554. So the next question then is: is there any way to cause IVOR1 to be asserted in the MPC5554?

Of the 4 listed sources of machine check:

- p_mcp_b is not supported by the MPC5554

- I don't have cache enabled (L1CSR0[CPE] and L1CSR0[CE] are 0 and all ways are disabled)

Which leaves the 2 possible sources:

- ISI, ITLB error on first instruction fetch for an exception handler

- Write bus error on buffered store or cache line push

The 2-bit ECC would seem to be a form of bus error. Jumping to an unimplemented area would result in a TLB miss and I assume would cause an instruction storage exception. But can I say that all possible sources under these 2 categories are subject to e1143 (and therefore will not take IVOR1)? What is the scope of this erratum?

Thanks again.

[lukaszadrapa]

Hi,

I checked it and IVOR1 can be triggered in this way: set IVPR and IVOR4 to point somewhere out of all MMU TLB entries and then generate IVOR4 by some peripheral. Second option is to inject double bit ECC error at first instruction of IVOR4 handler. The result is the same because description talks about ITLB error and about Instruction Storage exception.

It's not possible to inject errors to cache, so there's no this option. It's possible on newer devices.

Regards,

Lukas

[mikesfn]

What if INTC is configured for hardware vector mode, such that IVOR4 is not used? Would the same apply at the first instruction of any of the hardware vectors?

Thanks,

[lukaszadrapa]

Hi,

I did quick check using HW vector mode and I got IVOR3 in case of double bit ECC error and IVOR14 in case of TLB miss. So, I can see this does not apply to HW vector mode.

Regards,

Lukas

[mikesfn]

Good to know! This is exactly the behavior that I have seen, so I wanted to make sure I wasn't doing anything wrong.

So to summarize, In hardware vector mode:

1) 2-bit ECC error on data access => IVOR2

2) 2-bit ECC error on instruction fetch => IVOR3

3) TLB miss on read/write => IVOR13

4) TLB miss on instruction => IVOR14

Thanks for your help.

[lukaszadrapa]

Yes, that's it, I have confirmed the same behavior on my side.

Regards,

Lukas