PPC600 Family Debugger | 12
©
1989-2022
Lauterbach
Problems with Memory Access
For processors of some device families (esp. MPC82XX/MPC83XX), it is important that
no unimplemented
memory addresses
are accessed by the debugger. Unimplemented memory means address ranges which
would cause a
data access exception
when accessed by the target application in the current target state.
Memory that is only available after target initialization, like SDRAM is unimplemented memory until initialized
(e.g. a
window (or the stack view in the Register window) to SDRAM directly after reset). Also,
virtual addresses are unimplemented if the memory management unit is currently disabled or the address
unmapped (e.g. a Data.List window to Linux code at 0xC0000000 directly after reset).
The effects of accessing unimplemented memory are temporarily flickering memory windows up to
permanently hanging memory buses, which can only be recovered by a reset. The debugger can rarely
detect if a memory bus is hanging or not. Typical values displayed in dump/list windows are 0x00000000,
0xDEADBEE0, 0xDEADBEE1 or “????????” (bus error).
Hints for safe memory accesses:
•
directly after reset, set R1 to zero before opening the register window (which includes the stack
view)
•
directly after reset, close all windows that display data from SDRAM etc. which is not accessible
directly after reset
•
MPC82XX: close the peripheral view window before SYStem.UP. Usually the IMMR base
address is different after reset and after target initialization. Always set the right base address
with
SYStem.Option.BASE
before opening the peripheral view.
•
Protect the debugger from accessing unimplemented memory using
MAP.DENYACCESS
.
FAQ
Please refer to our Frequently Asked Questions page on the Lauterbach website.