|
|
|
 |
Breakpoints and HLL steps do not work on MPC85XX. (MPC85XX_P10XX_P2020_BSC913X)
|
| |
| Ref: 0176 |
|
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.
|
|
|
|
|
Breakpoints are not working properly or stop working completely. (MPC85XX_P10XX_P2020_BSC913X)
|
| |
| Ref: 0177 |
|
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".
|
|
|
|
|
Debugging critical interrupts on MPC85XX. (MPC85XX_P10XX_P2020_BSC913X)
|
| |
| Ref: 0178 |
|
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.
|
|
|
|
|
I cannot write data to the internal SRAM. (MPC85XX_P10XX_P2020_BSC913X)
|
| |
| Ref: 0146 |
|
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.
Example:
Data.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.
Example:
'Data.Set ASD:0x50000000--0x5003FFFF %BE %QUAD 0'
if SRAM is configured to start at 0x50000000.
|
|
|
|
|
SYStem.Option.FREEZE seems not to have any influence on the timers/counters. Is it possible to let the timers/counters run even when a breakpoint is hit or the cores are halted?
|
| |
| Ref: 0416 |
|
The SYStem.Option.FREEZE setting just uses the debug related registers to influence the timer / counter behavior when the target enters the debug halted state.
QorIQ CPUs typically offer an additional register in the RCPM, called CTBHLTCR or TTBHLTCR.
If the corresponding bit for a specific core in this register
- is set to 1, the SYStem.Option.FREEZE setting can handle both: To let the timers run or to freeze them during the core is in the debug halted state.
- is set to 0, the timers will always be frozen in the debug halted state, regardless of the SYStem.Option.FREEZE setting.
|
|
|
|
|
SYStem.Up does not work on my new board, how can I analyze the problem using the debugger? (MPC85XX_P10XX_P2020_BSC913X)
|
| |
| Ref: 0397 |
|
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.
|
|
|
|
|
What causes "emulation pod configuration error" when trying to start the debug session?
|
| |
| Ref: 0105 |
|
This error can have several 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 automatic detection (SYStem.DETECT CPU).
- The CPU on the target is not supported by the used debugger software version. Please check if a new version is available in the Downloads section.
In any case please check the AREA window (Menu: View - Message Area) for further information.
|
|
|
|
|
Why does the CPU stop unexpected after the operating system booted? (MPC8540_MPC8560)
|
| |
| Ref: 0167 |
|
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)".
|
|
|
|
|
Why does the debugger stop at a wrong address with error message "imprecise debug event" when a breakpoint is set? (MPC85XX_P10XX_P2020_BSC913X)
|
| |
| Ref: 0201 |
|
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".
|
