I agree, in priciple, with what's said here, with the exception that I don't generally put my debugger in the target system. When I'm using a resident debugger in an environment where socketed ROM's and RAM's are present, as is normally the case when using commercial, off-the-shelf MCU boards, I generally use the debugger to make determinations about the optimal order of certain processes when running within that environment, and, frequently, this means controlling two or more systems at once.

Often enough, the task requires a mechanical process to be operating at the same time, and that is controlled by code residing in one or more of the MCU's. Often, the rate, or point in time, within the sequence, at which communication between MCU's takes place is critical. That can be juggled by the debugger. I generally download the resident code to the host PC, replace the Target ROM with a battery-backed RAM, upload the resident code, which now can be "tweaked". The code is patched such that the resident debugger gains control of the system on reset but can still run the code where it normally lives. Under normal circumstances, the UART used to serve the debugger doesn't exist in or is not used by the target system's code. In some cases, the debugger can live in a vacant ROM space on the target board. In others, it has to live within the debug-MCU. It must, of course, be a device that exhibits precisely the same timing as the target MCU, but have larger on-board memory space. Most of the time, however, it simply exists in an external ROM. Since it's not used in the target system except for these process-synchronization "tweaks," it's not necessary to have it resident in the deliverable code.

As I've written before, debugging is not testing. Testing takes place with the deliverable code and other code in the target system. Test procedures are designed to exercise/stress the system-under-test in a way that will exhibit it has met design criteria. Debugging is a process of eliminating the code's failures to meet these criteria.

The size of the debugger can be arbitrary, so long as it leaves sufficient code space for the target code in its entirety. The size of the target memory, however, doesn't require space for the debugger. The physical implementation may limit the flexibility of application of the debugger. That has to be taken into consideration when the initial hardware configuration is chosen.

RE