EMULATORS AND DEBUGGERS

The purpose of the PIC® microcontroller emulators and debuggers is to provide you with an interface into the executing part, allowing you to monitor actual data, external I/O pin signals and stop at specific locations in the application. Emulators replace the entire circuit whereas debuggers involve specialized hardware built into the MCU to allow you to monitor the execution of the device in the application. In the debugging process, emulators and debuggers can be invaluable for identifying the state of the device and the circuitry it is connected to as part of the characterization and verifi- cation steps of failure analysis. Unfortunately, they are often not used for this purpose, instead they are used as an integral part of the development process. The danger of using an emulator or debugger as a development tool is that the possible resulting application is not fully thought out and can have numerous problems that are hard to find.

There is a fine line between PIC microcontroller emulators and debuggers. The reason for the difficulty distinguishing between the two is the similar operation of the two types of devices. The emulator replaces the microcontroller chip with a special chip that consists of a microcontroller with a high speed interface to an emulator, allowing the operation of the chip to be controlled and monitored. A debugger consists of a PIC MCU chip with specialized hardware that allows control of the processor and the ability to sample different registers. The primary difference between the two consists of the debugger’s need to allocate two or three I/O pins to the controller connection (the emu- lator does not sacrifice any I/O pins for this purpose), and communication of the debug- ger to the control hardware is relatively slow (especially when compared to the emulator). If you are familiar with either the emulator or debugger, you won’t have any trouble working with the other.

There are four types of emulators that are available for the PIC microcontroller. While there are a number of low-cost emulators available (including the Emu-II pre- sented later in this chapter), the full device emulator (like the MPLAB ICE-2000) is the best device on the market to use. The first type of emulator is a simple hardware interface

emulator that is controlled by a PC or workstation (see Fig. 5.1). In this type of emu- lator, simulator code in the PC runs the PIC microcontroller application and accesses the emulator pod’s I/O pins. This type of emulator is very inexpensive, but probably is the least accurate of the three types in terms of timing and electrical behavior of the I/O pins. Using a PC with a PIII processor and a high speed interface, the actual speed of the application will be approximately the same as what the PIC microcontroller would produce although there would probably be some significant differences in edge to edge timing.

The pin operation can be difficult to properly simulate using discrete chips, but a CMOS PLD could be designed to accurately model the PIC microcontroller’s pin behav- ior. This problem could be eliminated by writing a small PIC microcontroller applica- tion that allows a PC to interface with it and remotely control the operation of the I/O ports as is shown in Fig. 5.2. This emulator is the same type as the circuit presented later in this chapter (the Emu-II) and takes advantage of the PIC16F87x family of PIC micro- controllers, which can read and write internal program memory. The Emu-II uses this feature to load and execute code in the PIC microcontroller as is shown in Fig. 5.3. This type of emulator is often called a downloader and can be created quite inexpensively, but the limited program memory of the PIC microcontroller means that only relatively simple operations can be implemented.

The emulator concept presented in Fig. 5.3 is extended to be built into many differ- ent PIC microcontroller devices that have ICD 2 debugger functionality built into them (Fig. 5.4). The 16F87x, PIC18, and many other PIC microcontroller part numbers have built-in serial port features that allow custom hardware to a synchronous serial port to access the different registers and functions of the PIC microcontroller via the MPLAB ICD 2 Puck, which provides a USB interface to the PC and a synchronous serial inter- face to the emulated (debugged) chip. As noted above, a selection of I/O pins (often MCLR#, RB3, RB6, and RB7) is required for the emulator functions and using these pins for this purpose reduces the total number of pins available to the application. For some devices, like the 18-pin parts, these pins are part of the only full 8-bit port avail- able, which means that often the application cannot run the full, unchanged application with the ICD 2 debugger active.

The last type of emulator is the most expensive, but it does address all the issues raised by the other methods that have been presented. Built into every PIC micro- controller chip are the I/O pins that can be used by external hardware to control the operation of the PIC microcontroller as well as provide a separate memory to exe- cute out of. To provide access to these I/O pins, a special type of package (known as a bondout chip) is used. The bondout chip package is used to interface to the appli- cation and the emulator so that if any damaging voltages or currents are driven into the emulator by the application, this is the only part that has to be replaced. The cost for a bondout chip is on the order of $500, which, though expensive, is a lot cheaper than replacing a $2,000 emulator. The block for this type of emulator is shown in Fig. 5.5.