Of course I know debugging and use it. I did not ask "how to debug or what is debugging or what are the advantages of debugging". I just wondered how ICD works at the hardware level. So as an example, in icsp, MCLR pin is pulled-down and hex data is sent over a pin. I wonder what is the concept of working of a debugger hardware.
The concept? Maybe this will be of your interest...
The PIC16F877 was the first Microchip Microcontroller to have in-built debugging capabilities. The actual silicon area used for the debug facilities is tiny compared to the major peripherals. Microchip has keep the operation of the debug facilities pretty well under raps, however it doesn’t take much reading between the lines to work out how the actual debugging facilities are implemented.
The heart of the ICD is the breakpoint address register. This register is set with an address where you wish to break execution and examine the registers. When the Program Counter equals the Break Point Address, the PIC places the Program Counter Address on the Stack, as would happen with any interrupt and jumps to 0x1F00. This is the start of that all special debug code.
The debug code starts by preserving the Status Register, then moves down the chain making sure everything is recorded in it’s exact state when the break point occurred.
Now the question is, How to get the data into and out of the device?
We already know RB6 & RB7 are used for ICSP. The pin-out description names them as the In-Circuit Debugging pins as well as the Serial In-Circuit Programming Pins. Maybe there are additional ICSP commands for the debugger?
However to enter programming mode, we would have to reset the part and raise MCLR to VPP and after all wasn’t the ICD capability suppose to take minimal silicon? Why not simply synchronously bit bang the data in and out of the two pins using software support. This is what is actually done.
So forget the bit in the pin description about RB6 and RB7 being the In-Circuit Debugging Pins. They are in Microchip’s implementation of the ICD, but they are not set in concrete thus you could bit bang any two disused pins in your device. Not to say RB6 and RB7 aren’t the obvious choice as they are also used for in-circuit programming.
You could use the Asynchronous Serial Port to do such a task. You can all ready find bootstrap programs which read a program in on the serial port and burn it to portions of flash, then execute it. You could easily further this to include In-Circuit Debugging Capabilities without the need for a second control microcontroller or VPP programming voltages.
The next obvious question is how to set the Break Point Register? My guess would have been though the in-circuit programming protocol but as already discussed, this is not the case. It must be set from with in the program/execution environment.
Leisurely readying the ICD manual, you rellies two things. (a) you must leave the first program location as a NOP and (b) the processor breaks only after the instruction is executed. Put two and two together, and assuming the power on reset value of most registers is Zero, you could guess that on Power Up, the processor executes the NOP, then a break point interrupt occurs and execution jumps to the debug code at 0x1F00. . . . A reasonable assumption.
Now, if the program must write to the breakpoint address register, where is it?
Unimplemented data memory locations which read as ‘0’ is probably not much use, thus leaving two “Reserved” registers at 0x18Eh and 0x18Fh. Too easy? It is.
So what looks like a quite a little complicated debugging facility is nothing more than a breakpoint address register, a comparator and interrupt.
Source:
http://wearcam.org/seatsale/programs/www.beyondlogic.org/pic/icd.htm
