Troubleshooting Invalid Device ID Errors

This article 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.

program_hex.png

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).

Note: the MPLAB X IDE or IPE software handles this operation when you issue a program command.

When everything is working OK, the programmer will read the Device ID from the PIC microcontroller and identify the device (Figure 1a).

got_device_id2.png

Figure 1a: Reading device ID

When something goes wrong the programmer will not be able to read the Device ID and an error will be given (Figure 1b).

invalid_device_id.png

Figure 1b: Unable to read device ID

Entering Program Mode

The two main methods to place a device into Program Mode are as follows:

  1. Applying a high voltage on the MCLR/Vpp pin
  2. 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.

Fig2.png

Figure 2: High voltage Vpp entry method

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:

  1. Briefly drive MCLR high, then drive it low.
  2. Clock the 32-bit key sequence onto the PGD pin.
  3. Drive MCLR high within a specified period of time and hold it in this state.
Fig3.png

Figure 3: Low voltage, serial key entry method

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

Step 1: 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:

Fig4.png

Figure 4: Checking the signals at the pins of the PIC microcontroller using an oscilloscope

The MCLR/VPP pin can be checked first. Figures 5 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 (Figure 6).

Fig5.png

Figure 5: Information related to VPP voltage level and rise time from the programming specification document

NOTE: The values shown in Figure 5 are taken from the programming specification for one particular device. It may be different depending on the device used. Always refer to the programming specification for the specific device being used.

Fig6b.png

Figure 6: Programming voltage VPP high level and rise time

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 Figure 7 for an example of what would be seen on a functioning setup. If needed, a closer examination of the voltage level and timings can be checked against the parameters in the programming specification.

Fig7.png

Figure 7: Programming data and clock signals, PGD and PGC

Step 2: If the signals on the programming pins show a problem, then the signals should be checked along the path from the PIC microcontroller to the programmer. For example, if there is no signal present on a pin, or if the signal present has an incorrect voltage level, this could indicate an issue. The objective is to find if the source of the problem is coming directly from the programmer or if it is happening at some point between the programmer and the PIC microcontroller.

Step 3: To isolate the programmer from the target board hardware, the user can disconnect the programming signals VPP, PGD and PGC from the target board, if possible, and leave power connected. The programmer will not attempt to enter program mode without power being connected, so it must be present. Once the programming pins are disconnected from the board they can be checked with an oscilloscope. This will show what the signals look like without being affected by the target board hardware.

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 connected. As well as the programming pins, there are other pins which are necessary for proper operation during program mode. Refer to section "Pin Connections Needed for Program Mode" above.
© 2024 Microchip Technology, Inc.
Notice: ARM and Cortex are the registered trademarks of ARM Limited in the EU and other countries.
Information contained on this site regarding device applications and the like is provided only for your convenience and may be superseded by updates. It is your responsibility to ensure that your application meets with your specifications. MICROCHIP MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WHETHER EXPRESS OR IMPLIED, WRITTEN OR ORAL, STATUTORY OR OTHERWISE, RELATED TO THE INFORMATION, INCLUDING BUT NOT LIMITED TO ITS CONDITION, QUALITY, PERFORMANCE, MERCHANTABILITY OR FITNESS FOR PURPOSE. Microchip disclaims all liability arising from this information and its use. Use of Microchip devices in life support and/or safety applications is entirely at the buyer's risk, and the buyer agrees to defend, indemnify and hold harmless Microchip from any and all damages, claims, suits, or expenses resulting from such use. No licenses are conveyed, implicitly or otherwise, under any Microchip intellectual property rights.