FAQ for JTAG-PQ3


Breakpoints and HLL steps do not work (MPC85XX)
		Breakpoints and HLL steps do not work on MPC85XX
	In order to work with software or on-chip breakpoints, for this processor it is necessary that the Debug Interrupt Vector (IVPR+IVOR15) points to an address with a valid instruction in memory. Ensure that there is also a valid MMU entry for this address. We recommend placing a NOP followed by RFCI at this address. These two instructions at the debug interrupt address are also the prerequisite for SYStem.Option.FREEZE (freeze the time bases when CPU stopped). Also keep in mind that the software running on the target can change the interrupt vector registers and memory contents any time (usually during system initialization). You should then write NOP RFCI again to the new address before using any breakpoints.

Breakpoints are not working properly (MPC85XX)
		Breakpoints are not working properly or stop working completely
	To use breakpoints, the debugger relies on the MSR_DE (debug enable) bit to be set permanently. If the MSR_DE bit is disabled and the CPU hits an on-chip breakpoint, the regarding debug event is stalled until the MSR_DE bit is enabled again. The debugger can not prevent this bit to be cleared, therefore it depends on the target code's handling of this bit. There are three events that can cause this bit to be cleared: Target code clears MSR_DE by MTMSR instruction. The only workaround is to remove/change this instructions. Machine Check Interrupt clears MSR_DE. The CPU clears MSR_DE upon entering a machine check interrupt. Workaround: Add code at the beginning of the machine check interrupt handler to restore MSR_DE. Critical Interrupt clears MSR_DE. The CPU clears MSR_DE upon entering a critical interrupt. See FAQ "Debugging Critical Interrupts".

CPU stops unexpected when booting Linux (MPC85XX)
		Why does the CPU stop unexpected when Linux is boooting?
	The debugger can not differentiate between hitting a breakpoint and the CPU entering a power-save mode. If the DOZE bit in the HID0 register is enabled and the CPU enters the IDLE loop, the debugger will halt the CPU. The solution is to disable power-save modes for Linux. A workaround would be to disable the DOZE bit in the HID0 register, when the CPU stops for the first time.

Debugging Critical Interrupts (MPC85XX)
		Debugging critical interrupts on MPC85XX
	When debugging critical interrupts, two issues have to be taken in concern: CPU clears MSR_DE upon entering the critical interrupt handler. Software and on-chip breakpoints will overwrite the original CSRR0 and CSRR1 contents. There are two workarounds for this issue: Set SYStem.Option.CIntDebug ON. The debugger will restore MSR_DE on entering the critical interrupt and restore the original CSRR0/CSRR1 when a breakpoint was hit. Patch the interrupt handler code. On entry save CSRR0/CSRR1 and restore MSR_DE. Before exit restore CSRR0/1 to the saved values. Breakpoints can be used safely between the two patch locations.

Error Message: "emulation pod configuration error" (MPC85XX)
		Error message "emulation pod configuration error" after starting the T32 ICD software
	This error can have three sources: The CPU selection in the SYStem window does not match the CPU on the target. Check if the selection matches the processor on the target. Try to use auto detection (PPC..XX selection) if available. The CPU detection failed. Check the JTAG connection to the target. The CPU on the target is not supported by the used debugger software release. In most cases there is additional information given in the AREA window.

Imprecise Debug Event (MPC85XX)
		WHy does the debugger stops at a wrong address with error message "imprecise debug event" when a breakpoint is set?
	When a breakpoint is hit while MSR_DE is disabled, the debug event will not cause the CPU to stop. Instead, the debug event is stalled until MSR_DE is enabled again. In this case, the address where the debug event occurred is unknown, therefore it is called imprecise debug event. If an imprecise debug event ocurrs, the CPU will stop at an address after MSR_DE has been enabled. To prevent the CPU from stopping at an imprecise debug event, it must be ensured that MSR_DE is permanently set. The debugger will set MSR_DE every time the CPU is started, but it can not prevent MSR_DE from being cleared by the application. There are two possible actions for target code to clear MSR_DE. One is to directly write to MSR using the MTMSR Rx instruction. Check if Rx has the MSR_DE bit (0x0200) set. The other action is to indirectly write using the RFI instruction and the SRR0/1 registers. In this case, check SRR1 for MSR_DE. For Linux, patch following files (not all are available in all versions): head_e500.s head_fsl_booke.s reg_booke.h MSR_DE will also be cleared upon entry of critical interrupts. See FAQ "Debugging Critical Interrupts".

Initializing internal L2 SRAM (MPC85XX)
		I cannot write data to the internal SRAM
	If you can neither write nor read the internal SRAM, first check if the SRAM is configured and if there is a correct MMU TLB entry for those address range. If you don't want to set up the MMU, you can also use the memory class A: to bypass the MMU. (e.g. d.dump a:0x50000000). If you can already see the SRAM contents and just fail to write to it, you have to initialize the SRAM because of the ECC protection. For correct initialization, you have to write at least 32 bytes at an aligned address in SRAM (e.g. 'D.S ASD:0x50000000--0x5003FFFF %BE %quad 0' if SRAM is configured to start at 0x50000000).

Copyright © 2008 Lauterbach Datentechnik GmbH, Fichtenstr. 27, D-85649 Hofolding, Germany Impressum
The information presented is intended to give overview information only.
Changes and technical enhancements or modifications can be made without notice.
Last generated/modified: Aug-27-2008