Connecting Your Custom PCB to a Programmer/Debugger
All Microchip programmers and debuggers use In-Circuit Serial Programming™ (ICSP™) to program and debug the target microcontroller or microprocessor. This page provides information required to interface your custom development board with our programmers and debuggers.
In-Circuit Serial Programming™ (ICSP™) Considerations
A debugger, emulator, and programmer use a serial signaling scheme to program a target device in-circuit. A debugger and emulator use the same scheme to debug a target device in-circuit. The signals utilized are the clock and data signals defined in some data sheets as PGC and PGD or ICSPCLK and ICSPDAT. Additionally, MCLR/Vpp is used as either a high-voltage programming signal or an attention indicator to the device.
These signals are not dedicated for programming and debugging only, but are shared with a port pin or alternate peripheral. Generally, most devices use ports RB6 and RB7 as the default primary ports.
For trouble-free in-circuit programming and debugging, you must plan carefully to avoid any problems during the application development or production phase of the product. The proposed implementations are discussed in the following sections.
Recommended ICSP Implementation Configuration
The signals PGC and PGD are active bidirectional signals driven by the tool and target device during a typical programming or debugging session. These signals follow the programming specification and device algorithm. To minimize programming times, the signals are clocked at a fast rate of speed. Any additional obstructions or loads can distort the signals sufficiently enough to cause either intermittent or hard failures and prevent programming.
Keep these signals free of any other passive circuits or active logic in the application. This will ensure trouble-free debugging and programming sessions.
Another benefit of this configuration is that cable length and/or type may be negligible as there will be fewer reflections from cable mismatches.
Additionally, the MCLR/Vpp signal is used by the development tool to provide the voltage used for programming some devices or to signal attention. In instances where the application has a large capacitor, it will cause the signal rise and fall time to degrade. This will hinder the ability of the tool and the device to communicate effectively.
It is recommended to keep the signal pulled up to VDD with a 10K resistor and to utilize the power-on timer features of the device to ensure a proper power-up sequence.
The ICSP power connection from the tool to the target device assembly must use the operating Vdd voltage of the device, not the system. For example, if the system voltage is 5V but the device voltage is 3.3V, then the ICSP power connection should be 3.3V.
A matching operating voltage is required so that logic levels remain compatible between both the development tool and the target device.
Alternate ICSP Implementation Configuration
In some cases, especially with low pin-count devices, the pins must be utilized by the application.
If this is the case, as a minimum, resistive isolation is required between the device and the application's active node. This will ensure that both the application circuit and the development tool are able to drive the programming pins (PGC and PGD) to ground and to the proper VDD levels. The figure below depicts this configuration.
The resistive isolation value will differ depending on the application and how it is being used. Values ranging from 1K to 10K are suggested. In any case, ensure the levels on PGD and PGC can be driven to their appropriate logic voltage levels.
For isolating MCLR/Vpp, especially when the application uses a voltage supervisor, refer to technical brief TB087 (DS91087) for an in-depth discussion.
Communication Channels
Some devices have the flexibility to use one of several communication channels or pins for programming and debugging. These channels are generally referred to in datasheets as PGCx/PGDx, where x is the channel number identifier. As mentioned earlier, these channels are often multiplexed with some peripherals (I2C™, SPI, A/D).
If your application uses those peripherals and pins which are common to the default PGC/PGD pins, you must select a different channel and make provisions for the required ICSP connections. Likewise, when using MPLAB® X IDE to communicate with the target using this new channel pin assignment, you must ensure that the Configuration bits in MPLAB X IDE match the connection channel in your target.
For some devices, programming speeds can be slower on PGC3/PGD3 because they cannot make use of certain programming enhancements (i.e., a programming executive). Consult any datasheet errata for details.
Grounding and AC Applications
AC line-powered applications that are not referenced to the ground can present a voltage potential difference to a debugger, emulator, or programmer referenced to earth ground or PC return through the USB connector interface of a PC. This can cause damage to both systems.
 | Warning: Electric Shock Hazard Using the development tool without ensuring ground isolation will result in damage to the tool or the target system as the full AC mains voltage will be applied. This condition can be hazardous to the operator in the form of an electric shock. Therefore, take adequate precautions to avoid this situation. |
In these instances, the development tool must be isolated. Carefully consider the ground system and signal return connections before connecting the tool to the target. For hot or floating applications, a USB self-powered isolated hub should be used between the PC and the tool to provide isolation from the PC through the USB cable (see Figure 1).
USB-isolated hubs such as the following are suggestions:
- High/Low-Speed 4-port USB HUB, Model UISOHUB 4, B&B Electronics Mfg. Co.
- High-Speed, 7-port USB HUB, Model HUB7i, SEALEVEL Systems, Inc.
- Keterex Inc., Single USB port, Model P/N KXUSB-150.
- IFTOOLS Gbr, Single USB port, Model ISOUSB-HVC.
| Warning: Electric Shock Hazard Using an optoisolated USB hub will create a hot area (marked with the dotted red line in Figure 1 above). This condition can be hazardous to the operator in the form of an electric shock. Therefore, take adequate precautions to avoid this situation. |
Oscillator Circuit Setup
The following oscillator considerations address the proper setup of software and hardware.
Primary Oscillator
Often when starting a new project with a debugger or emulator, there is a high probability that the default settings of MPLAB X IDE will not match the specific configuration of the target application since there is a wide range of oscillator variations offered by the device. These differences between the MPLAB X IDE default settings and the unique target requirements cause a message to display in the Output window such as “The target device is not ready for debugging. Please check your Configuration bit settings and program the device before proceeding.” This is the result of an oscillator configuration mismatch between the target hardware setup and the default Configuration bits in MPLAB X IDE. To correct this, set the Configuration bits to match the oscillator settings of the target configuration.
For debugging operations, the application (target) oscillator must be functioning before in-circuit debugging can take place. Ensure the oscillator configuration and the MPLAB X IDE Configuration bit setup are configured properly. For example, if your application uses a 20 MHz crystal oscillator, select the HS (High Speed) selection in MPLAB X IDE. For any other applicable device oscillator modes, consult the device datasheet.
Crystal Oscillator Timer Oscillator/Secondary Oscillator
If a header board or Processor Extension Pak is used to connect to the target, there may be problems with starting the 32 kHz crystal resonator. To avoid potential problems, consider the following:
- Ensure the 32 kHz crystal is connected near the device footprint.
- Keep all lines as short as possible in the target application without unnecessary discontinuities such as PCB interconnect vias and test points.
- Minimize any capacitive loading on these nodes.
- Avoid using a socket for the placement of the crystal and capacitor. Solder the devices directly to PCB pads.
Target Power
The MPLAB REAL ICE in-circuit emulator cannot power a target board. This makes it different from the other debuggers. Therefore, the target board will need to have its own power supply when using the emulator.
The optional accessory MPLAB REAL ICE Power Monitor (AC244008) allows the MPLAB REAL ICE In-Circuit Emulator to power the target board, as well as monitor the current and voltage of the target or device.
Troubleshooting Invalid Device ID Errors
This section explains what could cause an Invalid Device ID error and provides guidance on how it might be resolved.
Background
To get a program running on a PIC® microcontroller, you have to compile the code into a hex file and then download (program) this hex file into the PIC.
To program the hex file into the PIC, the device must first be put into a special operating mode called Program Mode. Once in Program Mode, the data from the hex file can be sent to the device through programming pins on the PIC.
A programming tool (known as a programmer/debugger), such as PICKit™3 or MPLAB ICD 3/PM3/REAL ICE™, can be used to put the PIC into program mode and program the hex file data into the device. There are different programming algorithms used, depending on the PIC microcontroller, so the programmer must find out which device it is connected to and then use the appropriate algorithm. To do this, it enters program mode and attempts to read a register in the PIC which contains a device-specific identification number (the Device ID).
When everything is working OK, the programmer will read the Device ID from the PIC microcontroller and identify the device:
When something goes wrong the programmer will not be able to read the Device ID and an error will be given:
Entering Program Mode
The two main methods to place a device into Program Mode are as follows:
- Applying a high voltage on the MCLR/Vpp pin
- Clocking a 32-bit key into the program data pin (PGD).
Which method is used depends on the specific device being programmed.
Once in program mode, the device’s program memory can be accessed and programmed using the program data (PGD) and program clock (PGC) pins.
High-Voltage ICSP™ (In-Circuit Serial Programming)
To place the device into program mode using this method, the programmer holds the PGC and PGD pins low and raises the MCLR/VPP pin from 0 V to VIHH (high voltage level). The timing requirements for these transitions are shown below.
Refer to the device programming specification document for the meaning of the parameters P1 etc.
Low-voltage ICSP Using a Key Sequence
The second method used to enter program mode does not require a high voltage on the MCLR/VPP pin; instead, it uses a 32-bit key sequence ("MCHP" in hex format) that is clocked onto the program data pin (PGD). Specifically, the steps taken by the programmer are as follows:
- Briefly drive MCLR high, then drive it low.
- Clock the 32-bit key sequence onto the PGD pin.
- Drive MCLR high within a specified period of time and hold it in this state.
Troubleshooting
Pin Connections Needed for Program Mode
Program mode operations require the use of the programming voltage pin (MCLR/VPP), the programming data pin (usually labeled as PGD, PGED, or ICSPDAT), and the programming clock pin (usually labeled as PGC, PGEC, or ICSPCLK). In addition, this mode requires that the power pins be appropriately connected, i.e. all VDD and VSS pins must be connected, as well as the AVDD and AVSS pins. If the device has VCAP, ENVREG, or VBAT pins, these must be connected too. The Programming Specification document for each device, available on the device web page, will detail this information.
Checking the Programming Signals
Use an oscilloscope to verify that all the signals on the programming pins (MCLR/VPP, PGD, and PGC) conform to the voltage level and timing specifications and that these signals are present on the actual device pins, as shown in the following figure:
The MCLR/VPP pin can be checked first. The following figure shows the high-voltage level and rise time specification for the voltage on the MCLR/VPP pin as listed in the programming specification document and an oscilloscope measurement of these parameters on the MCLR/VPP pin.
For the PGD and PGC pins, a visual check on the oscilloscope will confirm if both the pins are active, the voltage levels are close to the VDD voltage level, and if the square waves are not too rounded. Refer to the following figure for an example of what would be seen in a functioning setup. If needed, a closer examination of the voltage level and timings can be checked against the parameters in the programming specification.
Common Causes
Here is a list of common reasons for getting the "Invalid Device ID" or "Failed to get device ID" error:
- Bad connection between the programmer and the programming pins on the PIC microcontroller. This could be the result of connecting the wrong pins, or an unstable mechanical connection.
- External components on the programming pins. Any components added to the programming pins could be interfering with the programming signals.
- Not all pins are connected. As well as the programming pins, there are other pins that are necessary for proper operation during program mode. Refer to section, "Pin Connections Needed for Program Mode" above.
Correcting Crosstalk With dsPIC30FXX Devices
In some cases, a crosstalk problem may exist when a dsPIC30 DSC device is being programmed. Due to the locations of the PGC and PGD pins, crosstalk may degrade the signal and cause the debugger or programmer to fail to program the target device.
To correct crosstalk in this situation, do not use the cable that comes with the debugger. Instead, construct an RJ12 modular cable made from a 6-connector flat satin modular cable such as Interstate WI WICTSS-2206 or equivalent. Keep the length as short as possible, preferably less than 6 inches. Also, remove the jacket from the cable, so that the conductors are far apart from each other (especially the PGC and PGD signals). The standard modular cable is wired as shown below, that is, RJ12 pin 1 on one end connects to RJ12 pin 6 on the other end. This solves the problem in nearly all cases.
dsPIC30FXX Devices and Clock Postscaler
In some applications that make use of the clock postscaler, certain precautions need to be taken to ensure that communication with the debugger or emulator is maintained throughout a device interrogation and a programming operation.
With the dsPIC30F series of devices, such as the dsPIC30F60XX, dsPIC30F40XX, dsPIC30F30XX, and dsPIC30F20XX, that have the clock prescalers as an optional clock mode, the ICSP sequence can get out of synchronization and cause programming operations to fail. This happens because the instructions are clocked in a bit at a time and the prescaler also divides the serial data instruction stream.
What further complicates this issue is when applications also use FRC as the clock source and the target power is used. In these situations, the application code that sets up the oscillator postscaler in the OSCCON register begins executing immediately after power-up. Any subsequent MCLR or device Resets do not reset OSCCON, which causes attempts to communicate via the serial channel after this point invalid.
A workaround for this scenario in development is to run from an external crystal or oscillator source. The oscillator needs to be disabled and the target power cycled to clear the OSCCON register to program the device once more.
Additionally, a long delay can be inserted prior to the postscaler configuration setup so the debugger and programmer tool can identify the device and still leave enough time to invoke an erase operation to take place before OSCCON is modified by the application.
Alternatively, consider not using the postscaler during general code development and add the postscaler configuration only as the application development nears completion. For devices in this situation, the MPLAB PM 3 programmer can be used to dynamically switch power and may have enough current (<250 ma) to power up the target completely and keep the OSCCON register cleared.
PIC32MX and iFlowtrace™
The MPLAB® REAL ICE™ In-Circuit Emulator or MPLAB ICE 4 in-circuit emulator can work with PIC32MX device MIPS® iFlowtrace™ (if available on the device – consult the device data sheet).
The PIC32MX architecture provides a method of program flow tracing where trace data is compressed, encoded, and transmitted on four data lines and one clock line. This data is transmitted at key points or non-sequential instructions (e.g., branches, jumps) in the program flow. The cycle-by-cycle trace can then be reconstructed by MPLAB X Integrated Development Environment (IDE) and displayed in the trace window.
To take advantage of this feature, some provisions must be made on the target, namely that five lines on the device be dedicated for tracing (four data + one clock). These lines cannot be used for other data or a garbled trace may result.
