| 1 | Why is the memory window update very slow at bad addresses? |
| 2 | Why is the local variable window update very slow when the PC is at the beginning of a function? |
| 1 | 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. |
| 2 | 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. |