What can disable Machine Check exceptions?

[bobgrimes]

I am trying to implement a Machine Check exception handler, and am having mixed results.  For reference, I started with the IVOR1 handler from Example MPC5744P 1b+2b_FLASH_ECC_error_by_UTEST_area_read GHS614.  (I started with that example, found it does as advertised, and based my handler on its IVOR1 handler.)  All went well in my test app; an intentional divide-by-zero caused the handler to be invoked.  However, when I added it to our app, the divide-by-zero no longer causes it to be invoked.

I then removed (through conditional compilation) most of our app until the handler gets invoked, and sure enough, it works, so I know that all the wiring is correct (e.g. vector table, linking in the handler, etc.).  I then started adding app code back in until it stopped working, and narrowed it down to one particular module; if I remove that module, the machine check gets handled, while if I include the module, no machine check.  The problem is, of course, the module has nothing to do with exceptions, interrupts, or the like!

Unfortunately, the module in question is not easy to debug for this sort of issue, as it is rather distributed (it is app state machine, in C, modeled after the GoF State pattern; I am not familiar with this area of our app, either).  So while I am not at a dead end, the path forward is unclear enough that I am looking at it a different way - specifically, the topic of this question - what can disable Machine Check exceptions?  How can I tell if they are enabled or disabled?  

Thanks!

[bobgrimes]

Excellent catch, David - thanks!  Curious they thought it would be a good idea to alter mathematical law!

[davidtosenovjan]

Your description does not make too much sense to me, but I will try to answer your questions.

What can disable Machine Check exceptions?

-

Please refer to the e200z759n3 Core Reference Manual, Rev. 2, section

7.6.2.1 Machine Check Causes

Machine check causes are divided into different types, as follows:

1) Error report machine check conditions

2) Nonmaskable interrupt (NMI) machine check exceptions

3) Asynchronous machine check exceptions

To point 1) MCSR register is updated when the machine check interrupt is taken.

Table 7-9 lists all sources of these errors.

Error report machine check exceptions are not gated by MSR[ME] bit.

To point 2) NMI exceptions are not gated by MSR[ME] bit.

To point 3) Interrupts due to asynchronous machine check exceptions are gated

by MSR[ME] bit.

How can I tell if they are enabled or disabled?

- If some sources are disabled then it must be to asynchronous machine check exceptions being disabled by MSR[ME] bit

I would recommend to investigate MSR (see Table 7-5. MCSR field descriptions) and MCSR register content at the beginning of ESR.

[bobgrimes]

Hi David.  I checked the MSR register after the Machine Check exception should have been triggered, and the MSR[ME] bit is SET; therefore, asynchronous MC exceptions are enabled.  So why aren't I getting any?  Maybe it's time to examine my assumptions, mainly that a divide-by-zero instruction will cause a (presumably asynchronous) Machine Check exception; is this true?

To clarify my problem, I set up a handler for Machine Check exceptions (IVOR1).  In our app with much stuff disabled, a C assign-by-zero statement will cause the IVOR1 handler to be called; however, when I re-enable the rest of our app, no exceptions are triggered.  As far as I know, we do not disable these exceptions, and indeed, I checked (per your suggestion) and the MSR[ME] bit is indeed set.  So I am again stuck!

[davidtosenovjan · Accepted solution]

I have been looking into EREF manual to divide instruction description. It is does not supposed to cause exception, behavior is always defined:

In case floating point, it would leads in IVOR33 (Embedded Floating-point Data interrupt) not in IVOR1 (Machine Check)

[bobgrimes]

Yeah, my description doesn't make too much sense - nor does the problem! :smileyhappy:

Seriously, thanks for the pointers (e.g. MSR and MCSR); I'll look into

these later and report back. If a divide by zero operation causes an

asynchronous machine check exception, you may well have found the issue;

it'll be up to me, of course, to find out where we are messing with

the MSR[ME] bit.

Thanks!

On Tue, May 2, 2017 at 10:35 AM, davidtosenovjan <admin@community.nxp.com>