Searching \ for 'Debugging (ICD vs ICE vs whatever)' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page:
Search entire site for: 'Debugging (ICD vs ICE vs whatever)'.

Truncated match.
PICList Thread
'Debugging (ICD vs ICE vs whatever)'
2000\03\21@201253 by William Chops Westfield

face picon face
There are nominally three levels of debugging, I think.  I'm most familiar
with them on rather large systems, but the same levels seem to exist in
smaller embedded systems.

1) Debugginng via external event.  You write code, put it on your system,
  and see if it works.  When you're desparate, you put printf's in the
  appropriate critical sections of code, so you can see where it is and
  what it thinks the state of the world is (for small systems, you might
  be able to toggle some unused signals in meaningful ways.)  This is
  painful and time consuming.

2) Debugging via CODE.  I think the "ICD" like devices fit in here.  Here,
  you can insert breakpoints into your executable code, and have some
  sort of supervisor snatch control away and let you look at the internal
  state of your program.  If you're lucky, you get visibility at a source
  code level, with appropriate logical symbols.  If you're less lucky,
  you only have visibility at the assembly level (unless that's your
  source, too!)   Key identifying feature: multiple code breakpoints.

3) debugging via HARDWARE.  This is your ICE.  Specialized hardware lets
  you debug based on internal state of the processor, and allows the
  "supervisor" from (2) to be completely independent of the code being
  debugged.  Key identifying feature: breakpoint on memory address

A personal observation is that there is a sort of double-humped learning
curve.  If you're at (1), there are certain features that you're just DYING
for in (2), and you can jump on them immediately.  But to learn the full
capabilties of (2) takes quite a while.  (I guess you're there when "going
back" is "impossible" instead of just paintul.)  I've lived most of my life
at (2), and I can see some things that I'd like to have (3) for, every once
in a while, but I don't NEED (3)  OTOH, there are people who use (3) most
of the time, and I bet THEY would have problems doing without it (even in
the same "application environment" I'm working in.)

The most useful features from each stage tend to migrate downward, as well.
Our pre-debugger environment included a "rom monitor" that allowed a single
breakpoint, deposit, examine, and continue.  It was a lot better than
nothing!  Larger processors or systems will tend to include some sort of
"address breakpoint" feature that software can trap, as well, perhaps using
VM hardware...

I'm not quite sure where simulators fit in.  In some sense, they're type (3)
systems - complete internal visibility.  It another sense, since they have
no real connections to the outside world, they can be useless.  I guess it
depends on whether you're debugging an algorithm or a troublesome piece of


2000\03\22@061405 by Andy Shaw

I think the nature of the problems also tends to influence what you do. My
real job involves working with big software systems on Unix and Windows
based computers. The standard debugging tools (type 2) work well in this
environment (mostly). However in an embedded environment timing and
interaction with external devices is often very important and the extra
facilities of an ICE are often a real advantage

In particular, I've just moved from an ICEPIC to an ICE 2000 the ICEPIC did
not have any sort of the trace, the ICE 2000 has a very very good trace. I
would not want to go back. So often it is good to be able to look at how did
I get hear, or to feed external inputs into the trace display and see how
they impact the software. In particular being able to see the effect that
interrupts have on things like timing etc. makes sorting out those oddball
special cases much easier.


2000\03\22@114111 by jamesnewton

face picon face
Well said, but I think there are two subdivisions of your level 2.
2A) is, yes, software via some minimal support in the instruction set. Its
the monitor / debugger system that is more useful and popular on processors
other than the PIC because they use special hardware and instructions to
support the debugging operation. Breakpoints are set by replacing the code
at that address with a special instruction and saving the original
instruction for later restoration. Some processors also have a "single step"
mode where the monitor routine regains control after every instruction is
executed in the main code. At that point, variable values can be checked
etc... and the single stepping continued or whatever. I write Win32Asm code
everyday and I use the WinDbg (free from Microsoft) on my '98 machine and it
just rocks... I can see everything happening, break on variable value
change, stack under/overflow, etc... But it doesn't really exist on the PIC
except as a cooperative system where code is added to assist in the
debugging. Sort of an advanced version of level 1. The Stickley register
monitor is a good example
but a real PIC monitor doesn't seem to be possible as the '877 even requires
an external interrupt (RB6 or 7) for the chip to shadow the PC so that the
interrupt (monitor) routine can report to the host where the main program
was and there is no single step. But what if the RTCC was set to interrupt
after one instruction when returning from the monitor ISR? The only problem
remaining is where did the main code branch to? Maybe on the next generation
of chips.

This level also has a serious problem for embedded controllers, as it does
not allow them to run at full speed while at the same time debugging by
running to breakpoint, etc... unless the code is modified and with flash
memory, this is just not a good idea. Even if the single step thing were
possible, it would interfere with timing on so many types of code that its
usefulness would be limited. Almost every project involving a PIC also
involves a close interface with external hardware.

There is another level:

2B) This is where the ICD works. Its not just software, but a combination of
hardware and software. A special interrupt on RB 6 or 7 causes the PC to be
copied into the reserved registers and a special interrupt routine reads
this and reports it along with the other register values to the host. Right
now, that is the ICD, but it could easily be a standard ASCII terminal. To
set a breakpoint, these same reserved registers are set to the address where
the monitor wants to regain control and the hardware in the target chip (a
compairitor) generates an interrupt when the PC reaches that address. Of
course, the monitor could also set any other register on command from the

The nice thing is that this hardware is built into each and every '877 made.
Its not only on the version of the chip used for ICE. It uses some resources
(pins and registers and code) and it can't do everything, but its heads and
shoulders above 1) or 2a) because it allows the chip to run at full speed
and does not require modification of the code (inserting breakpoint
instructions, etc...) to work.

But the best thing about level 2B) is that it is available in every
production part. Just set aside some code space and leave RB 6 & 7 and the
shadow registers free. If the production chip has a problem, you will be
able to see it. You can say, Ok, run the (original, unmodified) program to
this point and then stop and show me the registers. You know what values
should be there at that point and looking at what values are there, will
probably tell you what the problem is. You can single step if time is not an
issue, and modify registers on the fly to setup artificial tests.

Now, if we wanted to, we could re write the firmware so that it used the
USART to communicate directly with an ASCII terminal rather than through the
ICD module and the MPLAB software, connect RB 6 to RB 7 so that we could
generate our own hardware interrupt to get the shadow register set to PC for
external stops and even breadboard a little circuit that asserts RB 6,7 when
a hardware event occurs (when the PIC asserts RA.1, stop the program and
show me where it is in the code). Use the ROMZap or other boot loader for
programming the code and you have a complete development system in 1 chip
with the only cost being the RS232 interface. And you don't even have to
loose the RS232 port to your application since the bootloader and monitor
can serve as your serial interface ISR for the main application code.

James Newton 1-619-652-0593 NEW! FINALLY A REAL NAME!
Members can add private/public comments/pages ($0 TANSTAAFL web hosting)

{Original Message removed}

2000\03\23@124652 by Dan Michaels

Well, since I was named as a "comment: cc" recipient on this,
I'll comment. Lately, I've been sitting up in a tree [like Alan
Arkin in the movie Catch 22], watching the 'Free ICD' stampede
going on all around. Waiting for the dust to settle before I
can figure out how to sort it all out.

1. Let me say, as far as the overall "ICE vs ICD vs monitor vs
simulator vs whatever" debate is concerned, I feel that it's great
to have a whole closet full of tools, and one should use whatever
works best for them, and best for a particular situation. Every
man/woman his own king/queen.

While I have used them all, except the new ICDs, *personally* I
do not use either ICEs or simulators (or s.w. debuggers for PC
development) in normal ops, as I really dislike spending all that
time thumbing thru register values, step-by-step, screen by screen,
etc. Makes me feel more like an accountant, rather than an
embedded system artisan [this is just an *opinion*]. Now, there
*are* cases where only an ICE will suffice, but see next comment
(which reduces this requirement).

2. I think discussion of embedded system design/debug should be
always conducted in the context of "field-usability", and personally
believe that:


This is a way to attach a terminal/notebook PC to the device, either
in the field or on the bench, which allows you, via the "printable"
ASCII command set, to interactively interrogate the device. Some
customers may not want to spend the $$$$ for this feature, but
I feel you need to convince them to have it, since this can be a
real life saver for debugging systems in the field after problems

3. Following this philosophy means that the most useful way to
go, viz-a-viz ICE vs ICD vs monitor, favors the ICD or monitor
approach. If you can afford to leave 2 pins on the cpu *always*
dedicated for debug (or otherwise RS-232 communication) purposes,
and you *always* build a minimal level of debug capability into
*every* application s.w., then you can go to the system anywhere
it exists, hookup a terminal/PC, and begin to figure out what is
going on. Certainly, the advent of the cheap/free ICD and '87x
chip facilitates this approach.

4. At the simplest level, you can just put a basic register/port
monitor into any PIC chip. At a higher level, using the new '87x
chips, you can put in a complete debug/single step/execute/downloader
monitor which cannot be put into older PICs.

5. For me, the single best '87x/debug monitor s.w. would be one
that requires no onboard h.w. other than 2 wires that could be
connected to an RS-232 translator and an external ASCII terminal.

The debug s.w. itself should not require a massive PC support
utility, like the Magenta 668KB utility, but should be interrogatable
interactively and manually via the printable ASCII character set.
I wouldn't want to *ever* spend time writing custom host support
s.w. that would have to be changed as the embedded code changes
for different apps.

This is the direction I would go, if I were attempting to create
an '87x debug chip. To a great extent, it avoids the need for an
ICE, because I feel these are *most* useful when you have no other
way to communicate with the controller chip. Since I *always*
build a simple monitor and RS-232 comm into my apps as a matter
of course, I feel I can get by without an ICE. But if you need
one, you need one.

6. For "in-field" testing, it helps to be able to test the actual
chip that is sputtering where it is sputtering, so this favors
building some kind of debug/interrogation capability into *every*
chip. If you have to remove the board or pop out the cpu to do
testing, you've lost half the battle.

A simple on-chip monitor, accessable via ASCII terminal, can save
the day. A fancy '87x/debug/single-step/etc/etc monitor would be
better. If it doesn't require any additional h.w. or cpu pins
would be best.

If it turns out that all of this cannot easily be done with
the '87x, then it will still be great as a dev/debug/ICD platform,
but probably won't be of much use for dealing with in-field

Sorry this tome is a tome,
- Dan Michaels
Oricom Technologies

At 08:39 AM 3/22/00 -0800, you wrote:
{Quote hidden}

>{Original Message removed}

2000\03\23@161518 by Dan Michaels

At 12:43 PM 3/23/00 -0800, you wrote:
>Dan, your comments where dead on. I could not have said it better myself.
>Are you holding off on the board to see about ICD or monitor support?
>James Newton 1-619-652-0593

If you are referring to holding off on the WST board, as I
said, I am sitting in the tree waiting for the 'Free ICD'
dust to settle, so I can sort everything out. Since the WST
will not duplicate the ICD, nor probably ever be able to run
under MPLAB, it's probably best to watch and wait a bit longer.

- Dan Michaels

More... (looser matching)
- Last day of these posts
- In 2000 , 2001 only
- Today
- New search...