First, while I think you know that I know that you know that "JTAG" is not equivalent to "debugging"; if you say "debugging via JTAG", to somebody who might not be experienced in the field implies JTAG MUST be present to be able to debug. If we are really going to play with words, I'd suggest "on-chip debugging facility with serial interface, e.g. JTAG".
I'd call it "serial ISD" in the following text (please suggest a better term or acronym).

Second, let's investigate in depth, what can be gained and lost by using either one of the two techniques.

Both serial ISD and monitors feature program start/stop, internal resources (SFR/memories) inspection and manipulation, single-stepping (and "tracing").

The serial ISD is superior in having a possibility to include breakpoints, of code ("stop here") and "stop if memory area is accessed" type. Number of breakpoints is limited (as is the number of registers holding the breakpoint address). Conditional breakpoints are practically impossible; n-th pass breakpoints are possible but would be quite expensive - but if full-speed is not essential, complex breakpoints can be simulated in a similar way than in the monitors.
Monitors can have breakpoints, too, but not of the "memory area access" type and conditional/n-th_pass code breakpoints can be only simulated (hence no full speed). Moreover, also the implementation of code breakpoints in '51 (replacing the original instruction by a jump or call, 3 bytes minimum) requires the said von-Neumann-style RAM/Flash and involves a potential risk of mis-running program due to overwriting the following instructions (it happens when the breakpoint is set at the end of the routine, e.g. replacing a single-byte ret).

None of the two is able to produce full trace of various resources as a hardware ICE would, although there are some limited possibilities (e.g. in "trace" mode). Principially a trace memory could be implemented and interfaced to the serial ISD, but it would certainly be prohibitively expensive.

Serial ISD requires to have the "vehicle" (the "serial port"), and physical "connections" to all the resources inside the chip. This means some chip area increase, and also some speed penalty, as the "key points" have to be tapped at various points of the core and brought out usually to the chip's edge where the "extra" circuitry would sit. Jez might give exact figures for his '51 core. Outside of the chip, there has to be some physical interface (but that's the same for monitor as well), but more importantly, some software is needed on PC, serving as the user interface and providing some of the "automatic" functions.

Monitors are infamous for requiring/occupying resources which one needs for the application - they need some "hooks" (usually occupy one or more interrupt vectors), the "vehicle" (usually the UART) and of course, memories (RAM, stack, code memory). On the other hand, they are cheap, derivative-independent (save the requirement for von Neumann code memory), and easily expandable, upgradeable, correctable (it's only software, anyway). They come in two fashion - self-contained, requiring only a serial terminal program on PC; and the "core" type, performing very similarly to the serial-ISD, requiring extensive support from a PC application. It seems that the latter is more useful, but the former has the advantage of being "OS-independent", enabling "debugging everywhere".


Summary of pros (+) and contras (-):<pre>
serial ISD monitor
extra chip area needed - +
speed penalty - +
interrupt occupied + -
RAM/stack/code space occupied + -
vonNeumann code space needed + -
single stepping, stop&run + +
resources inspection + +
breakpoints + -
traces - -
PC application needed - +-
correctable - +
pins occupied +- -
various interface possible - +

In ASICs and freshly cooked '51 chips, there is a cross-over/compromise possible - the core might contain support for the breakpoints and some extra resources (a few bytes of RAM and a special code memory) normally invisible to the user, accessible not via a dedicated hardware, but via SFRs from the monitor program. I think this is a very good concept and in the '51 world it has been used in the TI's(BB's) MSC12xx chips.


I'd like to discuss this topic further with the intention of creating some FAQ-ish document on debugging tools, so please run down on what has been said here, tear it into pieces and comment on each of it. Thanks.


Jan Waclawek

PS.: history of ISD on AVRs: JTAG was first, but single-pin debugging is the bleeding edge now, both coexisting on the high-end Megas
PS2: in the '51 world, ADuC have single-pin insitu debugging, but with zero public documentation.