Quality Information in one Place . . .
|
The Debug Capabilities of the PIC16F877
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. Very little overhead for very useful feature. No doubt we will see the debug feature migrate to other processors.
Making your own ICD
Fancy making your own ICD? I wouldn’t imagine it would be any cheaper, considering the development time. Microchip has released the silk screen overlays and schematics for their ICD in Appendix A of the MPLAB ICD Users Guide (DS51184A). The code was suppose to be restricted, preventing you from making them. However d877.hex has appeared in the MPLAB 4.x directory. Upon closer examination of this file, you discover it’s the source code for the ICD complete with embedded (retlw x-opcode) debug code which is loaded into the target at 0x1F00.
The code is for a PIC16F876 device which is the little brother of the 16F877. The PIC16F876 is a 28 pin device with a few less I/O ports, and the Parallel Slave Port. What this means, is you can use a PIC16F877 as the heart of the ICD if you are having difficulties sourcing the 16F876.
What Microchip hasn’t released is the licensing information for the D877.Hex Is it freely available for private and commercial use? I’ve already seen some making derivatives of the ICD for commercial gain. My guest would be that they are using the D877.hex in it’s raw unaltered form, bearing in mind that dis-assembly is most cases is not legal either.
Revisions for the ICD
When Microchip released MPLAB v5.00 in March, they shipped new firmware for the ICD, firmware version 2.04 (MPL876.HEX in your MPLAB 5 directory). This gave the end user support for the PIC16F873/874, supposedly better serial communications and the ability to perform flash upgrades over the wire with one mouse click.
They also released a Engineering Technical Note ETN#21, “Upgrading MPLAB ICD Flash and Operating ICD below 4.5V”. This included two modifications, one for better support when operating the ICD from a supply voltage lower than 4.5V and the other to enable flash upgrades.
The first modification involved changing R21 and R22 which make up a voltage divider monitoring the VPP. These resistors were increased by a factor of 10 to reduce the load when low currents are available as a result of running the unit from under 4.5V.
Most of the early ICD’s included OTP 16C73B. These of course cannot be updated over the wire, thus the second modification is to replace the 16C73 with a 16F876 which is pin to pin compatible, only in a re-programmable flash version. This enables to user to update the code at a later date.
Making your own modifications
References
John Andrews (john.andrews@microchip.com), John Day (john.day@microchip.com)
"Debugging, In-Circuit Style", Circuit Cellar #109 August 1999
PICmicro Firmware is copyrighted by Microchip Technology Inc., and is intended for Microchip Development Tools only. Modified firmware code will not be supported by Microchip Technology Inc.