FAQs for JTAG-PQ3


The embedded tools company

Search FAQs



PDF document ( 60KB / 07-Sep-2016 )


TOP

CPU stops unexpected when booting OS (e.g. Linux) (MPC8540_MPC8560)

Ref: 0167
Why does the CPU stop unexpected after the operating system booted?

For MPC8560 and MPC8540 revision 1, the debugger can not differentiate between hitting a breakpoint and the CPU entering a low-power 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 low-power modes. A workaround would be to disable the DOZE/NAP/SLEEP bits in the HID0 register, when the CPU stops for the first time.
All other processors of the MPC85XX series are fully supported even with low-power modes enabled. The debugger will display the current power state in the status line, e.g. "running (doze)".

TOP

Error Message: "emulation pod configuration error" (MPC85XX)

Ref: 0105
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.


TOP

Board bring-up using the debugger (MPC85XX_P10XX_P2020_BSC913X)

Ref: 0397
SYStem.Up does not work on my new board, how can I analyze the problem using the debugger?

On MPC85XX, QorIQ P10XX/P2010/P2020 and PSC913x, this problem is often caused by a wrong bootstrap configuration. The typical indication is that the processor could be detected, but SYStem.Up does not work (see message AREA contents for information about the type of error).
In many cases, though not always, it is possible to perform memory accesses. When possible, memory access can be used to observe the Power-On Reset Configuration registers. This can be done using the following sequence:
    SYStem.CPU MPC85XX
    SYStem.DETECT CPU
    SYStem.MemAccess CPU
    SYStem.Mode.Attach
    PER , "Global Utilities,Power-On" /DualPort
When a wrong configuration was identified, but can not be fixed on the current target hardware, it is possible to override this setting through JTAG. Please contact bdmppcpq3-support@lauterbach.com for instructions to use the reset configuration override function.
Should memory access to the Power-On Reset Configuration registers fail (question marks shown in peripheral view), there is still a chance to get information about the bootstrap information. In this case also contact bdmppcpq3-support@lauterbach.com for instructions.

TOP

Breakpoints and HLL steps do not work (MPC85XX_P10XX_P2020_BSC913X)

Ref: 0176
Breakpoints and HLL steps do not work on MPC85XX

Affected Processors: MPC8540, MPC8541, MPC8555, MPC8560
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.

TOP

Breakpoints are not working properly (MPC85XX_P10XX_P2020_BSC913X)

Ref: 0177
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".


TOP

Debugging Critical Interrupts (MPC85XX_P10XX_P2020_BSC913X)

Ref: 0178
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.


TOP

Imprecise Debug Event (MPC85XX_P10XX_P2020_BSC913X)

Ref: 0201
Why does the debugger stop 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".

TOP

Initializing internal L2 SRAM (MPC85XX_P10XX_P2020_BSC913X)

Ref: 0146
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 © 2016 Lauterbach GmbH, Altlaufstr.40, D-85635 Höhenkirchen-Siegertsbrunn, Germany  Impressum
The information presented is intended to give overview information only.
Changes and technical enhancements or modifications can be made without notice. Report Errors
Last generated/modified: 22-Sep-2016