-
- Why is the memory window update very
slow at bad addresses?
- A typical BDM transaction between the debugger and the target
goes like this.
- Debugger requests a memory-read from target.
- Debugger polls target for end of read.
- Target indicates to debugger that the memory-read is complete.
- Target passes memory-read results to debugger.
-
- The problem is that a memory-read on a bad address causes a bus
fault error. A bus fault error looks just like a "memory-read
not done" to the debugger's polling routine. So the polling
routine must time-out before it can terminate. This time-out takes
a long time, resulting in very slow window update speeds. The solution
is to scroll the window so that bad memory is not visible.
-
- Why is the local variable window update very slow when the
PC is at the beginning of a function?
- This problem occurs only when the code contains local variable
pointers. At the very beginning of a function, the local variables
have not been initialized. This usually causes bus faults to occur
when the debugger resolves the variable's contents. Bus faults are
very slow as explained in a previous FAQ.
|
