WHile I agree with most of what you say, here, there are a few minor issues.

First of all, however, I'm not wanting to debate the virtues of ICE, JTAG, or debug monitor. I'm wanting to know whether there's a debug monitor with functions similar to CP/M's DDT or MSDOS' DEBUG.whatever with line-by-line assembly and disassembly capability, among its other features.

Apparently, there's not.

There's been a commentary suggesting it would be better to use JTAG, which none of the conventional MCU's in this family seem to support, though that's certainly an option with programmable logic. There's also been some commentary suggesting an ICE of one sort or another would be better. Both of these options are available. However, I prefer, for the purpose of solving my particular set of problems, to use a resident debugger. This is because (a) my code is small (<16KB), (b) a debugger can easily deal with hardware/software synchronization problems, (c) I'm not working in 'C' at this point, else I couldn't consider this approach, (d) an ICE won't deal with my programmable logic applications, and so on.

Now ... as for the specifics ...

While your assertion that "When new hardware features were added to the SBCs, the monitor program would need to be updated." may be true in some cases, it doesn't apply here. The target code is the target code, the monitor is separate, providing the ability to set breakpoints and subsequently examine the content of memory, hopefully reflecting the state of operation of an interface, AND it doesn't require any new features be added anywhere. In fact, that's why a debugger is so handy. The target code has to run up to the breakpoint in real time in order to allow examination of the state of an interface at a point of breakdown or potential breakdown, it doesn't have to operate at speed when interacting with the operator.

As it happens, the SiLabs part is not under consideration.

You've said "Most microcontroller projects use specific peripherals, and a debug monitor program would have to be built for each peripheral configuration. This means maintaining different versions for each product. Another point is why waste valuable ROM space (or FPGA logic!) on a debug monitor that your customers will never use?" but that's just not the case, particularly in the case of the logic. The logic doesn't change at all, nor does the debugger. Right now, however, I have to use one environment to do the assembly/disassembly just to patch a byte or two of code, while running the debugger on another. I'd just like to skip the movement back and forth. Back in the '80's, this sort of thing worked OK. I don't see why the mere fact that ICE's are now so ubiquitous, one should have to use 'em.

If I have several points of interest in a target code set, I can set more than one person to work on those problems, presumably saving some calendar space. If I have to buy an ICE for each one, I find that somewhat inconvenient. I can put the same debug monitor in each target system, allowing several programmers to work on the problems without having to step over one another. This isn't often necessary, but, since there are often hundreds of miles between the individuals collaborating on a project, it is a convenient alternative to flying everybody here so they can fight over the debugging hardware.

The things I need done can be done with an ICE. The things I need done can be done with JTAG. However, the things I need done can be done with a resident debugger as well, and that's less trouble.

Moreover, while an ICE can solve my problems on a specific MCU, if I want to use a different MCU, all bets are off. At a minimum, I have to buy another ICE. There are few MCU's that even support the notion of a resident debugger, and the 805x's are among them. I also use various MOTOROLA parts from time to time and among others, but those, and the 805x's can be dealt with in this way, and, if there were a commonly available 'C'-source for a debugger, I'd simply use that for all the MCU's that I have, capable of supporting both target code and a debugger. As stated, not all MCU's support that notion, but is is a familiar method, and, it would be nice, though not necessary, to use the "same" tool on multiple projects. I now there are toolsets including several ICE's that support exactly that construct. However, they require costly, easily damaged, and easily lost adapters that only solve the problem one at a time.

BTW, we never, Never, NEVER build test hooks into deliverable code.

RE