We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

AR# 17466

PowerPC405 - How do I debug PowerPC machine checks?


Keywords: PPC, 405, PPC405, Powerpc, PowerPC, Debug, Machine Check, Exception

Urgency: Standard

General Description:
Why is my PowerPC design causing a machine check? How do I debug machine checks?

A machine check is normally triggered by an access to a memory address to which no peripheral is mapped, i.e., no SDRAM, DDR, BRAM, UART, IIC, etc. This can be on the instructions side when the processor goes into the weeds or on the data side.


The first step in identifying the source of the machine check exception is to stop execution of the processor when the exception occurs. This can be done using two methods.

1. If interrupts have been enabled in the system where the machine check exception has happened, breakpoints can be used to identify the source of machine check exceptions. Set a breakpoint at $EVPR+0x200, where EVPR is the exception vector pointer register and 0x200 is the exception vector entry point for machine check exceptions.

Please refer to the PowerPC Processor Reference Guide for additional information regarding PPC exceptions. The PowerPC Processor Reference Guide can be found on the Xilinx Web site:


2. If interrupts have not been enabled and you do not have machine check exceptions turned on, i.e., if you have a simple standalone program that does not use interrupts, you can use the following technique to stop the processor on bus errors:

(XMD%) rwr msr 0x1000 Enable machine check exceptions
(XMD%) rwr dbcr0 0x83000000 Freeze processor on any exceptions

The second step is to load and run your program.

Now the processor will stop when a machine check occurs. You can find the next instruction that the PPC is going to execute after it returns from the exception in the SRR2 register. Now, when looking at the registers and the disassembly of the code, you can figure out which access generated the bus error/machine check. However, machine check instructions are imprecise, i.e., the processor can actually execute a few more instructions after an invalid memory access. So, when looking at the dissassembly, not only look at the last instruction before the SRR2 value, but also look at some instructions before that.

As an alternative to, or in combination with, the above, you can change the hardware design and hook up the DCR bus to the BExR (BEAR/BESR) registers in the PLB arbiter, the PLB2OPB, and the OPB2PLB bridge. These registers will contain the offending address.

See the documentation for the PLB arbiter, the PLB2OPB, and the OPB2PLB bridge cores for more information.
AR# 17466
日期 04/28/2006
状态 Archive
Type 综合文章