I have a PIC18LF1220 in 20-pin SSOP package running at 4MHz from internal clock source and 3.3 volts. I have soldered the microcontroller onto a pcb with a groundplane on the bottom layer and the pic is on the top layer. I'm using two 0.1µF ceramic bypass capacitors one for VDD & VSS and one for AVdd & AVss pair. I also have one 10kOhm pullup resistor on the MCLR pin. I have the programming header on the board just about 3cm away from the pic and couple of the first programming on this prototype board worked fine, but after these first programming runs ICD3 says the following:

program memory
Address: 0 Expected Value: 59 Received Value: 0
Failed to program device

This is the third pic chip on board that refuses to program again. I have had to change the chip every two new prototype programs as the same problem has always occured after two programming runs. Why is the pic refusing to reprogram after two previous programmings that worked fine? I had the previous program run all night to test it worked properly (just a simple pin blink program) and now it just won't do anything as it seems that the erase worked, but no new code was loaded (at least properly). This behaviour seems to be very consistent as all these three PIC's have died after trying to program them for the third time. Below is the complete message given by ICD3.

Connecting to MPLAB ICD 3...

Currently loaded firmware on ICD 3
Firmware Suite Version.....01.43.35
Firmware type..............PIC18F

Programmer to target power is enabled - VDD = 3,250000 volts.
Target device PIC18LF1220 found.
Device ID Revision = 7

The following memory area(s) will be programmed:
program memory: start address = 0x0, end address = 0x74f
configuration memory

Device Erased...

program memory
Address: 0 Expected Value: 59 Received Value: 0
Failed to program device

Could it be that this particular batch I have has some flash memory issues (I have verified this problem on three pics one after another). The chips I have here are all reported to be of revision 7 silicon by the ICD3. Below are the config bits I have been using if they could have something to do with the problem (I highly doubt that they would cause this kind of problem).

#pragma config OSC = INTIO2     // Oscillator Selection bits (Internal RC oscillator, port function on RA6 and port function on RA7)
#pragma config FSCM = OFF        // Fail-Safe Clock Monitor Enable bit (Fail-Safe Clock Monitor enabled)
#pragma config IESO = ON        // Internal External Switchover bit (Internal External Switchover mode enabled)

#pragma config PWRT = OFF       // Power-up Timer Enable bit (PWRT disabled)
#pragma config BOR = OFF         // Brown-out Reset Enable bit (Brown-out Reset enabled)
// BORV = No Setting

#pragma config WDT = OFF        // Watchdog Timer Enable bit (WDT disabled  (control is placed on the SWDTEN bit))
#pragma config WDTPS = 32768    // Watchdog Timer Postscale Select bits (1:32768)

#pragma config MCLRE = ON       // MCLR Pin Enable bit (MCLR pin enabled, RA5 input pin disabled)

#pragma config STVR = ON        // Stack Full/Underflow Reset Enable bit (Stack full/underflow will cause Reset)
#pragma config LVP = OFF        // Low-Voltage ICSP Enable bit (Low-Voltage ICSP disabled)

#pragma config CP0 = OFF         // Code Protection bit (Block 0 (00200-0007FFh) code-protected)
#pragma config CP1 = OFF         // Code Protection bit (Block 1 (000800-000FFFh) code-protected)

#pragma config CPB = ON         // Boot Block Code Protection bit (Boot Block (000000-0001FFh) code-protected)
#pragma config CPD = OFF        // Data EEPROM Code Protection bit (Data EEPROM not code-protected)

#pragma config WRT0 = OFF       // Write Protection bit (Block 0 (00200-0007FFh) not write-protected)
#pragma config WRT1 = OFF       // Write Protection bit (Block 1 (000800-000FFFh) not write-protected)

#pragma config WRTC = OFF       // Configuration Register Write Protection bit (Configuration registers (300000-3000FFh) not write-protected)
#pragma config WRTB = OFF       // Boot Block Write Protection bit (Boot Block (000000-0001FFh) not write-protected)
#pragma config WRTD = OFF       // Data EEPROM Write Protection bit (Data EEPROM not write-protected)

#pragma config EBTR0 = OFF      // Table Read Protection bit (Block 0 (00200-0007FFh) not protected from table reads executed in other blocks)
#pragma config EBTR1 = OFF      // Table Read Protection bit (Block 1 (000800-000FFFh) not protected from table reads executed in other blocks)

#pragma config EBTRB = OFF      // Boot Block Table Read Protection bit (Boot Block (000000-0001FFh) not protected from table reads executed in other blocks)
  • \$\begingroup\$ Have you tried powering the circuit separately rather than from the programmer? Just a thought, but maybe once you're running your blink program, it's causing a problem with the ICD3's power supply. \$\endgroup\$ Commented Aug 17, 2016 at 8:57
  • \$\begingroup\$ @RogerRowland I have tried both using the ICD3 to supply the power and external power source also without any success in trying to reprogram the chip. Both of them supplying 3.3v. Another weird thing is that I have been using PIC18F1220 (same chip as I know with narrower operating voltages) only difference being that it's a DIP packaged version. I haven't had any problems what so ever with that 18F1220 in dip package. \$\endgroup\$ Commented Aug 17, 2016 at 9:13
  • 1
    \$\begingroup\$ Does an Erase followed by a Blank-Check succeed? \$\endgroup\$
    – brhans
    Commented Aug 17, 2016 at 22:43
  • \$\begingroup\$ @brhans Did not try that, but the problem appeared to be just this erase thing as 3.3 volts is not enought to blow the code protect fuses, so some config bits cannot be cleared when using under 5 volts in programming phase. Don't know if that would be seen in blank check after erase though. \$\endgroup\$ Commented Aug 18, 2016 at 6:34

1 Answer 1


I think the bootblock protection bit may be prohibiting writing at 0x0 (?)

config CPB = ON  // Boot Block Code Protection bit (000000-0001FFh)
  • 1
    \$\begingroup\$ Hi - Interesting hypothesis except: (a) Those config bits are erased during a full device erase which, according to the OP's output, succeeds; (b) How would this explain why the programming only fails on the 3rd attempt, after 2 previous successes? If this hypothesis were true, and if that setting wasn't erased during a device erase, surely the 2nd programming attempt should fail? Therefore based on those 2 reasons, this hypothesis doesn't seem to fit the reported data. Or do you believe I misunderstood the hypothesis or the reported data? I'm happy to be corrected :-) \$\endgroup\$
    – SamGibson
    Commented Aug 17, 2016 at 16:20
  • \$\begingroup\$ Yes, this was the case! The problem was caused by that config bit as I was using 3.3 volts to program the chip and that wasn't enough to blow the code protection fuse. After increasing the voltage to 5 volts and clearing that bit I could program it again using 3.3 volts. Some of these pics require 5 volts in order to blow some of the fuses. When these fuses remain the same, they can be programmed using 3 volts. \$\endgroup\$ Commented Aug 18, 2016 at 6:29
  • \$\begingroup\$ Happy it worked out, as @SamGibson was right. It was a guess. \$\endgroup\$
    – peter
    Commented Aug 18, 2016 at 10:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.