MPC5746C Machine Check Exception (IVOR1) w/ SPI Example Code

[pstammii]

Greetings!

I am using the MPC5746C on a custom PCB with PEmicro Debugger. I am attempting to run an example SPI program provided by NXP, located at C:\NXP\S32DS_Power_v2.1\S32DS\software\S32_SDK_S32PA_RTM_3.0.0\examples\MPC5746C\driver_examples\communication\spi_pal inside my local file system. 

The pin assignments/connections on my custom board are inspired from the MPC5748G-LCEVB evaluation kit, but not exact. Hence, I changed the pin_mux and spi1/2 component configurations to be aligned with what our board supports and generated the Processor Expert code. The program builds.

I also followed the instructions at the following webpage and modified the physical connections to align with our board: S32 SDK: SPI PAL MPC5746C

When I run the program, inside main() the code calls SPI_MasterInit():

Inside SPI_MasterInit() the code calls DSPI_MasterInit():

Inside DSPI_MasterInit() the code calls DSPI_Set_MCR_Halt():

Finally, inside DSPI_Set_MCR_Halt(), when the program attempts to execute the first line inside the function, a Machine Check Interrupt (IVOR1) is raised.

At this point the execution is paused in an infinite loop. 

The cause of this issue is puzzling and my efforts to track it down have been unsuccessful. Is there any guidance that you can offer me to assist me solving this issue?

When I run the equivalent example on the MPC5748G-LCEVB, it works fine.

If it's helpful, here is what my MCSR register looks like:

Thanks for your time.

Kind Regards,

Paul

[davidtosenovjan]

OK, it does make sense now.

Bus error during reading from SPI_2.

I guess there is some mismatch between SPI_2 and DSPI_2 as these are different modules.

[pstammii]

Hi David,

I am not sure what is going on but I have tried running multiple NXP example projects using the built-in function from the processor expert, and among all of them what I am seeing in common is when a function tries to access a module register (like MCR) it triggers the IVOR1 exception handler and won't return to finish executing the rest of the code. Here's an example function: 

When the controller tries to execute the REG_BIT_SET32(&(base->MCR), ADC_MCR_PWDN(1u));, this is where the IVOR1 is raised and it won't execute.

I still haven't figured out the issue with the SPI module from before, so I tried moving on to other modules but I'm facing the same obstacle.

I've also tried commenting out the IVOR1 segments inside the startup files but instead of IVOR1, it just sends it up the chain to a different IVORn handler and the result is ultimately the same.

Would it be possible for you to view my project or attempt to execute it on your end and see if the issue  persists (I've atttached a .zip)? I would greatly appreciate any additional insights you can offer. Thank You.

[davidtosenovjan · Accepted solution]

If I run this code on my board it goes to IVOR1 as well because ADC registers are not available because Mode Entry transition didn't happen and device is not clocked according the setting.

Pay attention to Mode Entry module.

[pstammii]

Follow-up question:

Instead of manually coding the Mode Entry module, can I just use the clock_manager component in Processor Expert? Isn't that the point of it, to do the Mode Entry leg-work? Or no?

Thanks.

Paul

[davidtosenovjan]

Yes, the component configures ME setup, so it is it properly configured, it could be enough.

[pstammii]

Thanks David.

The issue was incorrectly configured clocks, which was not allowing the mode entry sequence to complete. Once I got that right I ended up just using the clock_manager inside Processor Expert to configure everything and initialized by calling the two functions below, which I learned about through some of the examples in the S32 SDK (the functions are in clock_MPC57xx.c). Just using the CLOCK_DRV_Init() processor expert function was not enough.

[pstammii]

Hi David,

I followed your advice and read up on the Mode Entry module in the reference manual.

I have added some code in the Initialize_Components(void) function within main.c to enable the clocks and peripherals, aiming to transition the chip to RUN0 mode. The primary issue I'm encountering now is that when I write to the MC_ME_MCTL register to transition to RUN0 mode (with the KEY and then again with the inverted KEY), the program hangs after the second write to MC_ME_MCTL. I have attached my latest project for your reference and testing. I would appreciate any insights or suggestions you might have regarding this issue. Thank you very much for your help. 

Below is a summary of changes I made to my project (and other observations) in light of the current state of the situation:

• I transitioned my configuration from the MPC5746_256 package to the MPC5746C_100 package, as the 100-pin package is what I'm using on my custom board
• The ADC1 MCR/MSR registers continue to show a value of 0x0 (I am not aiming to use ADC0, just FYI)
• I added a Power Manager configuration to my project, initializing it for DRUN mode, which appears to be the controller's default mode after RESET. My objective is to operate in RUN0 mode if possible, although the manual suggests the ADC should be operational in either DRUN or RUN0 mode
• I've also adjusted the clock settings, slowing down the FIRC to 8MHz and further dividing it to 1MHz for the FS80_CLK, which the ADC1 module uses. My concern was that a high clock speed might be contributing to the issue, so I reduced the clock speed to potentially increase the likelihood of proper functionality without adverse effects

As an aside: I was able to successfully run the ADC and SPI examples on the MPC5748G-LCEVB without needing to manually configure the Mode Entry module. Any idea why this might be the case?

- Paul

[pstammii]

I see your point regarding a potential mismatch.

However, inside the PE generated function "SPI_MasterInit()", it uses "DSPI_MasterInit()" so I am not sure how to disassociate the two...

Additionally, I am encountering the same problem with the IVOR1 exception even when I change the module from SPI_2 to a DSPI module. I also tried using the DSPI peripheral driver component rather than the spi_pal component...same result.

[davidtosenovjan]

Could you screenshot also MCAR register?

Interesting value is stored in MCSRR0 register as it should be address of instruction causing an IVOR1 exception (machine check) and you have 0xFFFF_C000 what's reserved region within PBRIDGE_A memory space.

[pstammii]

Hi David,

I ran the program again and realized that in the original screenshot I didn't capture the MCSRR0 register at the moment the exception is raised. Here is an updated screenshot taken at the proper time and including the MCAR register you requested. Thank you.