Thank you for responding to these questions. Since I'm not an ICD designer
(read: since I don't know what I'm talking about <GRIN>) but I enjoy the
topic, I've had a couple more thoughts....

Re: point 3:
If a hardware patch were installed (even as crude as just wiring one of the
port pins over to RB 6 or 7 and leaving it as an input most of the time)
that would allow the Debug code to assert the ICD interrupt, would the debug
code not regain control after executing a retI? Wouldn't the shadow
registers contain the value of the PC which was just retrieved from the top
of stack?

Re: point 2:
Can't a hardware breakpoint be set at the next instruction after the call?
e.g. the shadow registers are set to watch for the PC to match the address
of the instruction after the call.

---
James Newton (PICList Admin #3)
mailto:jamesnewton@piclist.com 1-619-652-0593
PIC/PICList FAQ: http://www.piclist.com or .org

-----Original Message-----
From: pic microcontroller discussion list
[mailto:PICLIST@MITVMA.MIT.EDU]On Behalf Of Darrel Johansen
Sent: Wednesday, April 26, 2000 15:31
To: PICLIST@MITVMA.MIT.EDU
Subject: Re: Q: ICD answers


There are some issues that have come up related to the ICD and MPLAB-ICE.
The answers are:
1. MPLAB-ICE 2000 does, and does not skid
2. MPLAB-ICD does skid, and for this reason F8 was not implemented
3. Reading the stack with MPLAB-ICD is not do-able

1. MPLAB-ICE 2000 has two ways of getting breakpoints:
     Software, wherein a HALT instruction is inserted into program memory.
     Hardware, wherein the emulator chip logic is toggled by the
emulator/analyzer.
The software breakpoint will not skid.  When reached, the HALT instruction
is removed and replaced by the original instruction at that address and the
program counter is backed up.  Software breakpoints are set by the right
mouse button and by the breakpoint dialog.
The hardware breakpoint always skids.  This is due, as has been pointed
out, to the way the PIC executes instructions while fetching the next.
Hardware breakpoints are set by the complex trigger dialog and by executing
Run>Halt (F5).

2. MPLAB-ICD has only hardware breakpoints, using the built-in debugger
modes of the 16F877.  As a result, a breakpoint operation always skids.
When using Step-Over, MPLAB-ICE inserts a software breakpoint at the next
instruction after a CALL.  In order to not impact the endurance of the
16F877 devices, it was decided not to implement this in MPLAB-ICD.

3.  Reading the stack might be able to be done in MPLAB-ICD, but there is
no way to find the value of the stack pointer. Executing RET from the ICD
debug code will "pull" the execution out of the debug code into the main
program memory.  Likewise, setting the PC is not easily done in the
MPLAB-ICD because the debug code runs in the upper program memory area.  If
the debug code changes the PCL then PCLATH, it gets "pulled out" of the
debug code area and debug control is lost.

Darrel Johansen