How to read MCSRR0/1 registers

[yuehedeng]

My code enter machine check ISR and the device is MPC5748G. Could any one tell me how to read machine check related registers, for example MCSRR0/1. The registers aren't listed in s32 IDE when debugging. I can't find the address of these registers.

Thank you.

[martin_kovar]

Hi,

please check the following thread. There is a solution for your issue.

https://community.nxp.com/message/635734 

MCSRR0 register is SPR570

MCSRR1 register is SPR571

Regards,

Martin

[yuehedeng]

Thanks， it's helpful. 

One more question how to go to the location I want in Disassembly window.

The code cause IVOR1 seems located in 0x01002C22, but I don't know how to go there and view the exactly code.

When I enter 0x01002C22, it doesn't go to there.

[martin_kovar]

Hi,

when you enter address 0x01002C22 to the window you marked in the picture and hit ENTER, you should see the code at the address.

Regards,

Martin

[yuehedeng]

That is what  I do at that time, but it still stays at _start line. Also I still have no idea about why machine check ISR happen. 

Do you have any idea about that? 

The source code is shown as below. And the attached rar is my project. 

SIUL2.GPDO[47].B.PDO_4n = 0;//--- It will cause machine check ISR when these two lines execution in sequence,
PIT_wait_micsec(2); // but if comment one of them, then everything works find, don't know why

[martin_kovar]

Hi,

I tested the project you had sent me and I am not able to get to the same state as you show at the figure above. I used Lauterbach debugger and also PeMicro with S32 Design Studio and in both cases I got stuck at the state showed at the figures below. I have never reached to DSPI2SendBuffer function which causes the problem.

It seems, you have different conditions at your system (maybe some other devices connected to the microcontroller).

Is it possible for you to create some simple project (as simple as possible) which demonstrates your issue?

Regards,

Martin

[yuehedeng]

Thank you.  This issue happens after I port freertos.Now I find the root cause: during initialize extended spi device, it will trigger SPI receive interrupt, then kernel will switch task context. But at that time, tasks haven't been created, so the TCB is NULL, then machine check interrupt happen because illegal operation.