START NOW WITH MPLAB^® ICD

ICD vs. ICE

The in-circuit debugger (ICD) is a cost-efficient alternative to an in-circuit emulator (ICE). It can do many things that were previously done only with more expensive hardware, but the cost benefits come with a trade-off of some of the conveniences and some of the features of an in-circuit emulator. If an application is designed to be ICD compatible, this low-cost hardware debugger can do most of the same functions as an ICE. As opposed to an ICE, some of the requirements of the in-circuit debugger are:

• The in-circuit debugger requires exclusive use of some hardware and software resources of the target.

• The target PIC^® MCU must have a functioning clock and be running.

• The ICD can debug only when all the links in the system are fully functional.

An emulator provides memory and a clock, and can run code –even without being connected to the target application board. During the development and debugging cycle, an ICE provides the most power to get the system fully functional, whereas an ICD may not be able to debug at all if the application does not run.

On the other hand, an in-circuit debug connector can be placed on the application board and connected to an ICD even after the system is in production, allowing easy testing, debugging and reprogramming of the application.

Even though an ICD has some drawbacks in comparison to an ICE, in this situation it has some distinct advantages:

• A connection to the application after the production cycle does not require extraction of the microcontroller in order to insert an ICE probe.

• The ICD can re-program the firmware in the target application without any other connections or equipment.

MODULAR INTERFACE CONNECTIONS

MPLAB ICD is connected to the target PIC MCU with the modular interface cable.

The figure shows the interconnections of the MPLAB ICD to the modular connector on the target board. There are six pins on the ICD connector, but only five are used. The diagram also shows the wiring from the connector to the PIC MCU device on the target PC board. A pull-up resistor (usually around 10k Ohm) is recommended to be connected from the VPP/MCLR line to VDD so that the line can be strobed low to reset the PIC MCU.

The figure below shows the active MPLAB ICD lines with some components that will restrict MPLAB ICD from functioning:

REQUIREMENTS FOR DEBUG MODE

To debug (set breakpoints, see registers, etc.) with the MPLAB ICD there are critical elements that must be working correctly:

• MPLAB ICD must be connected to a PC. It must be powered by an external power supply or the PC via the USB cable, and it must be communicating with MPLAB IDE software via the RS-232 or USB cable.

• MPLAB ICD must be connected as shown to the VPP, PGC and PGD pins of the target PIC or dsPIC MCU with the modular interface cable (or equivalent). VSS and VDD are also required to be connected between the MPLAB ICD and target PIC MCU.

• The target PIC MCU must have power and a functional, running oscillator.

• The target PIC MCU must have its configuration words programmed correctly:

- The oscillator configuration bits should correspond to RC, XT, RC, etc., depending upon the target design.
- The target PIC MCU must not have the Watchdog Timer enabled.
- The target must not have code protection enabled.
- The target must not have table read protection enabled.

Sequence of Operations Leading to a Breakpoint

If the above conditions are met, then these actions can be performed when MPLAB ICD is set as the current debugger (Debugger>Select Tool):

• The application code is programmed into the PIC MCU’s memory via the ICSP™ protocol.

• A small “debug executive” program is loaded into the high area of program memory of the target PIC MCU. Since the debug executive must reside in program memory, the application program must not use this reserved space. The debug executive typically needs about 0x120 words of program memory.

• Special “in-circuit debug” registers in the target PIC MCU are enabled. These allow the debug executive to be activated by the MPLAB ICD.

• The target PIC MCU is held in reset by keeping the VPP/MCLR line low.

Typically, in order to find out if an application program will run correctly, a breakpoint is set early in the program code. When a breakpoint is set from the user interface of the MPLAB IDE, the address of the breakpoint is stored into the special internal debug registers of the target PIC MCU.

Commands on PGC and PGD communicate directly to these registers to set the breakpoint address. Next, the Debugger>Run function or the Run icon (forward arrow) is usually pressed from MPLAB IDE. MPLAB ICD will raise the VPP/MCLR line to allow the target to run, the target will start from address zero and execute until the program counter reaches the breakpoint address previously stored in the internal debug registers.

After the instruction at the breakpoint address is executed, the in-circuit debug mechanism of the target PIC MCU “fires” and transfers the PIC MCU’s program counter to the debug executive (much like an interrupt) and the user’s application is effectively halted.

MPLAB ICD communicates with the debug executive via PGC and PGD, gets the breakpoint status information and sends it back to the MPLAB IDE. The MPLAB IDE then sends a series of queries to MPLAB ICD to get information about the target PIC MCU, such as file register contents and the state of the CPU.

These queries are ultimately performed by the debug executive. The debug executive runs just like an application in program memory. It uses some locations on the hardware stack (usually just one or two) and, typically, about fourteen file registers for its temporary variables.

DEBUG RESERVED RESOURCES

When developing with MPLAB ICD, be aware of the device resources reserved for debugging. Check the MPLAB IDE on-line help or the README file of the current software to find out details of the processor being used. In general, in-circuit debugging uses the following on-chip resources:

• MCLR/VPP is shared for programming.

• Low-voltage programming (LVP) is disabled.

• PGC and PGD are reserved for programming and in-circuit debugging.

• One or two stack locations are used by the MPLAB ICD debugger.

• Several general purpose file registers are reserved.

• Upper words of program memory area are reserved for the debug executive code.

• The PIC18FXXXX MCU shadow stack is not available while debugging. The application can use the shadow stack, but cannot debug a return from a fast interrupt or fast CALL routine because the ICD will overwrite the shadow stack when it gets a breakpoint.

HEADER BOARDS FOR LOW PIN COUNT DEVICES

Since in-circuit debugging requires the loss of clock, data and MCLR pins, MPLAB ICD development with low pin count is not practical. A special -ICD device is used with the MPLAB ICD to provide separate clock, data and MCLR pins and frees all normally available pins to the user.

This special -ICD device is mounted on the top of the header and its signals are routed to the MPLAB ICD connector. On the bottom of the header is a socket that plugs into the user's target via the stand-off connector.

PROGRAMMER MODE

When using the Programmer>Program selection to program a device, the debug executive will not be loaded. In this mode the MPLAB ICD can only toggle the MCLR line to reset and start the target. A breakpoint cannot be set, and register contents cannot be seen or altered. The MPLAB ICD programs the target using ICSP.

No clock is required while programming, and all modes of the processor can be programmed, including code protect, Watchdog Timer enabled and table read protect.

Note: A header board is required to debug smaller pin count parts with the MPLAB ICD. These parts can be programmed without the header by connecting the VPP, PGC and PGD lines as described above.