ICSP Microchip issues ..or all me?

[Poe]

I'm accustom to programming PICs in a socket like the Picstart plus.  To enter the 21st century, I got a used PICkit3 and tried ICSP.

So far, not so good.  Is it me or the PICkit?

I soldered a 16f883 to a breakout board with a decoupling cap, bulk cap and a LED/resistor tied to one pin.  The Vpp, PGC, PGD pins are only connected to the PIC and less than an inch away.  Continuity all checks out.  Configuration is setup to use the internal oscillator and MCLR is internally tied to VDD.

Although the Vdd and ground pins are connected to the PIC, I powered the 'target' from a bench supply(5V).  Made sure that the "Power target circuit from PICkit3" checkbox was unchecked before doing that.  MPLAB shows a 5.0V on the PICkit3.

It worked for a dozen times, then started giving me errors.  "Target ID not expected value"... even though it's the same value (all zeros) that it was when it was working.

I looked at the programming lines and they look correct, I think.  I see Vpp ramp up to 13V then a few milliseconds later I see a burst on the data and clock lines.

The user manual talks about excessive capacitance on the Vdd line.  The other lines I can understand, but if I'm powering the target from a bench power supply, why should this matter?

I removed power to the target and used the PICkit3's power, it worked a couple times.  Now it appears completely random. 

Do I need anything else, or should I simply be able to power a PIC with an external 5V supply, and attach the unused pins to the PICkit?

Does the MCLR/Vpp pin need a pullup to Vdd as in their chart?  Does the PGM pin need tied to ground?

Edit:  Swapped out the PIC for a new one and removed the bulk cap.  The Target ID is still all zeros, but MPLAB doesn't give an error.  Very odd. 

Appears to work better without the bulk cap... not sure why that's an issue as I have it powered for at least a minute before programming.

SOLVED: PGM pin needs pulled low when using a PICkit to program.  Contrary to datasheet, it doesn't matter what config bits are set.

[Maxlor]

As per the PICkit 3 User Guide, page 22, the setup you describe seems correct. The only thing I'm not sure about is whether the internal pullup for !MCLR suffices. Maybe try adding the external pullup resistor and see if that improves things?

I've also noticed that with some computers, not all USB sockets work equally well. With some, I've notice the PICkit3 sometimes freezing up (reconnect it to fix it), switching sockets helps. And it's not just limited to the PICkit3, I noticed the same with my Saleae too.

[Andy Watson]

Does this version have the low-voltage programming option? If so, make sure that the appropriate pin is tied to the inactive state (Usually RB3).

[Howardlong]

PICstart plus? Blimey! I think I may have one of those somewhere from a decade+ ago!

MCLR should always have a 10k pullup unless it's in production on a chip that has an option to use it for GPIO. For debugging, I don't recommend overriding MCLR with a GPIO. MCLR is fundamental to the programming and debugging function.

PGM is only for low voltage programming, forget about it, but make sure your config bits have LVP off.

I have some 16F886's here, same chip just more memory, so zip up your code directory and I'll take a look.

[dannyf]

Very odd

Read the datasheet and it wouldn't be odd anymore.

[Andy Watson]

PGM is only for low voltage programming, forget about it, but make sure your config bits have LVP off.

Don't forget about it! I have experience of this programming problem with the 16f877 and its like. Sometimes the parts programmed ok; sometimes not. The parts always behaved in the PIC programmer but were random when using the ICSP on the product board. The problem was cured by pulling RB3 to VSS with a 100k - i.e. RB3 cannot be allowed to float during programming - irrespective of the LPV bit -  even in high-voltage programming.

[Poe]

Disconnecting the PICkit and reconnecting didn't appear to do anything.
Low voltage programming is disabled in the configuration, but I'll try that next.

I tied a 10k from MCLR to Vdd and it did... something. 

When powered by the PICkit it almost always connects with a device ID of all zero.  No error.

When programming it says:
"Failed to get Device ID"
"Programming/Verify complete"
...about 10% of the time.

When powered by the power supply, it say:
"Target Device ID (00000000) does not match expected Device
ID (00002020)."

When programming..
"Programming...
The following memory regions failed to program correctly:
Program Memory
Address: 00000000 Expected Value: 00002826 Received Value: 00000000
Programming failed"

I don't see anything in the datasheet that would explain the device ID thing.  Maybe a page number hint?

[Howardlong]

Just hacked up a breadboard with the 886. It is the same chip but more memory.


Here is my code, with the minimum to get going.

Code: [Select]

#include <xc.h>

#pragma config LVP=OFF
#pragma config PWRTE=OFF
#pragma config WDTE=OFF
#pragma config MCLRE=ON

int main(void)
{
TRISBbits.TRISB5=0;

while (1)
{
PORTB=0b00100000;
PORTB=0b00000000;
}
}

I first tried this on MPLAB 8.92 with ICD 3, no problem.

I then plugged in PICkit 3 to test that, I got the same error as you, ie wrong target. Weird.

Switched to MPLAB X 2.30. Migrated the project. Worked fine with the PICkit 3 (it re-loaded some new PICkit firmware).

Switched back to MPLAB 8.92 and it started working, again it reloaded the PICkit firmware.

[Howardlong]

PGM is only for low voltage programming, forget about it, but make sure your config bits have LVP off.

Don't forget about it! I have experience of this programming problem with the 16f877 and its like. Sometimes the parts programmed ok; sometimes not. The parts always behaved in the PIC programmer but were random when using the ICSP on the product board. The problem was cured by pulling RB3 to VSS with a 100k - i.e. RB3 cannot be allowed to float during programming - irrespective of the LPV bit -  even in high-voltage programming.

Never encountered that before, but worth keeping in mind. I have a device I designed 12 or 13 years ago based on the PIC16F877/877A, I don't know how many were sold as I gave away the IP, but it's many thousand. That has RB3/PGM floating during programming, and it's the end user who programs it via a serial port. Maybe if it's already had its LVP bit programmed it's a problem, I don't know.

[Gixy]

Useful article of well known Olin Lathrop on this subject:
http://www.embedinc.com/picprg/icsp.htm

[Howardlong]

I think you are right.

I just erased the chip, unplugged everything, started again, and the fault reappeared.

Code: [Select]

Resetting...
PK3Err0040: The target device is not ready for debugging.
Please check your configuration bit settings and program
the device before proceeding.

Programming...
Programming/Verify complete

Running...
PK3Err0040: The target device is not ready for debugging.
Please check your configuration bit settings and program
the device before proceeding.

Put link to ground on RB3/PGM, erased, tried again, no problem.



Learn something new every day! Nice tip, although I don't use these old chips with LVP much these days it has to be said.

Edit: can't make an erased chip fail with an ICD 3 or Real ICE either, maybe they did something fancy with those debuggers. But yes, thanks for the tip, I won't forget that one.

[Poe]

SUCCESS!

Connecting PGM to ground via a 10k resistor worked.  Thank you so much!

 

[dannyf]

That has RB3/PGM floating during programming

That depends on the lvp fuse setting.

[Howardlong]

That has RB3/PGM floating during programming

That depends on the lvp fuse setting.

Yes we figured that out already. Unfortunately when the part is new or erased, the default is that LVP is enabled.

It is not in the device's Main data sheet. It is hidden away in the programming spec, under the low voltage programming bit description in a rather vague way, but more specifically it is in the errata. Yet another reason to always read the errata, even a brief scan is worth it so you are aware.

[dannyf]

It is not in the device's Main data sheet.

Then you didn't read the datasheet carefully, because it is right there, in plain sight and couldn't have been more clearly stated.

[Howardlong]

It is not in the device's Main data sheet.

Then you didn't read the datasheet carefully, because it is right there, in plain sight and couldn't have been more clearly stated.

Go on then, put us out of our misery, where is it stated in the DS for the device in question that you need to hold PGM low while performing a high voltage program?

[Poe]

Gotta say, if it's there in the datasheet I don't see it. 
Maybe he meant errata?  I see it there and I must have glossed over that bit initially.
No matter.  Thanks again for the help.

[Howardlong]

Gotta say, if it's there in the datasheet I don't see it. 
Maybe he meant errata?  I see it there and I must have glossed over that bit initially.
No matter.  Thanks again for the help.

Indeed, suddenly it's all been a bit quiet on the matter too I notice. I am sure it was the DS itself that was being referred to, the programming and errata sheets I'd mentioned myself had been discounted.

Generally speaking, even if you don't know the ins and outs of a chip these days I find it's worth taking a brief look at the errata early on for an executive summary. It still hits me every once in a while though on new chips, wasting half a day on so on something that's not you.

Anyway, it'd not be half as much fun if we weren't learning something new every day.

[neslekkim]

It is not in the device's Main data sheet.

Then you didn't read the datasheet carefully, because it is right there, in plain sight and couldn't have been more clearly stated.

Go on then, put us out of our misery, where is it stated in the DS for the device in question that you need to hold PGM low while performing a high voltage program?

Page 27: http://ww1.microchip.com/downloads/en/DeviceDoc/41287D.pdf

"b) make certain that RB3/PGM is held low during entry into ICSP."

[Howardlong]

It is not in the device's Main data sheet.

Then you didn't read the datasheet carefully, because it is right there, in plain sight and couldn't have been more clearly stated.

Go on then, put us out of our misery, where is it stated in the DS for the device in question that you need to hold PGM low while performing a high voltage program?

Page 27: http://ww1.microchip.com/downloads/en/DeviceDoc/41287D.pdf

"b) make certain that RB3/PGM is held low during entry into ICSP."

Thank you, but I believe that only applies if Master Clear is disabled, and we have enabled the master clear pin, as the code showed. In addition even if it wasn't, it's either (a) or (b) that needs to be satisfied, and (a) is satisfied with the LVP config bit cleared in the code.

Code: [Select]

#pragma config LVP=OFF
.
.
#pragma config MCLRE=ON


3. If the device Master Clear is disabled, verify that either of the following is done to ensure proper entry into ICSP mode:
a) disable Low-Voltage Programming (Config Word 1<12> = 0); or
b) make certain that RB3/PGM is held low during entry into ICSP.