PICKIT2 - 18F26k22 - Occasionally fails to program.

[davegsm82]

Anyone ever experienced this problem with the PICKIT2;

Programming fails using the standalone programmer application, using the Auto-import and Write function. Weird thing is if you manually Erase and write the PIC then it writes just fine.

The process fails at the Verification stage, usually around 0x0C00-0x0C02. When it fails, it actually does really fail, the device i'm programming boots ok but some text or graphics are garbled, suggesting there's some sort of spill-over into RAM or something.

Sometimes it programs fine, then starts to play up, then maybe later it starts working fine again. It's doing my head in!

Dave.

p.s. First post on the forum, so Hi!

[JPortici]

hi,
is the PK2 powering the board, or are you applying external power?
are the programming lines free or are you also using them for something else?

if you are powering the board from the PK2 during programming, i would suspect that your board is drawing too much power

by the way, i didn't even know that the 26k22 was supported by the pickit 2. must have been one of the last..

[davegsm82]

I've tried both powering the board from PK2 and from the internal rechargeable battery in the unit, the result seems to be the same either way :-/

The thing that gets me is the fact that it will fail to program from the 'Auto-import and write' or manual 'Write' buttons, but if you Erase FIRST and manually write, it works just fine.

Not sure when support for the 26K22 appeared, I suspect it was the last gasp for the PK2, as the 26K40 uses a different programming method (Similar to SPi apparently).

If anyone is familiar with the PK2 devicefile, do you know if it's possible to add the 'Erase' function before the device is programmed? from what I understand, this method is used for other devices which use EEPROM rather than FLASH storage.

[JPortici]

26k40 is a much newer family newest is k42 (k22 was released in 2010 vs 2016 vs 2017)
AFAIR device is always fully erased before programming, otherwise you can't reset the configuration bits

what is happening to you is strange indeed... as you say it seems device doesn't get erased

i do have a bunck of boards with 26k22 here and a pickit 2 somewhere, i could try if programming fails here too..

[KL27x]

The part where you have to erase the chip, first, got me wondering if your firmware has something to do with the problem. Some things I'd check off the list:

1. PK2 software > Tools > check "Vpp first program entry"

If that doesn't work I'd go to the firmware:
1. Try adding a delay as the first step in the code. A few mS. Just as a rule out. Or try another test firmware, just some nops and an END.
2. Program it however you have to, erase first, whatnot.
3. Then try to reflash this chip without erasing it.

[davegsm82]

26k40 is a much newer family newest is k42 (k22 was released in 2010 vs 2016 vs 2017)
AFAIR device is always fully erased before programming, otherwise you can't reset the configuration bits

what is happening to you is strange indeed... as you say it seems device doesn't get erased

i do have a bunck of boards with 26k22 here and a pickit 2 somewhere, i could try if programming fails here too..

Yea, it's very odd, could be a timing issue but I even added a 2 second delay to the start of the code to try and work around that. Made no difference in practice. I didn't know that the PK2 software does an erase before programming, it certainly never says it's doing so.

I've got some 26k40's, plus a PK3...but you know, PK3

The part where you have to erase the chip, first, got me wondering if your firmware has something to do with the problem. Some things I'd check off the list:

1. PK2 software > Tools > check "Vpp first program entry"

If that doesn't work I'd go to the firmware:
1. Try adding a delay as the first step in the code. A few mS. Just as a rule out. Or try another test firmware, just some nops and an END.
2. Program it however you have to, erase first, whatnot.
3. Then try to reflash this chip without erasing it.

Have tried (1 - VPP entry first) when I was getting this problem persistently, made no difference, neither did using fast or slow programming methods.

I tried adding a delay as detailed above but that didn't help, I could try some NOP's etc.

I should add that my program is relatively large, 80% of the Program memory is used and probably half the RAM.

Sorry this is all a bit vague, shame you can't upload hardware!

Thanks, Dave.

[JPortici]

i won't ever stop repeating myself. i'll rather have a PK3 over a PK2 any day, at least it's actually supported by X, IPE etc (and i overall prefer those over the older tool)

[davegsm82]

i won't ever stop repeating myself. i'll rather have a PK3 over a PK2 any day, at least it's actually supported by X, IPE etc (and i overall prefer those over the older tool)

While I admire your conviction, I will stick to my PK2. I have a PK3 and while it is a nice piece of kit, it's way less stable than the PK2. It's just not the same as using the PK2, I don't use X, I use MIKROE instead so that's not an issue and I actually make use of the UART tool which isn't an option with the PK3 and the 26K22.

[KL27x]

I have and use both.

1.Flexibility: PK2 can tolerate much more capacitance on the ISCP lines, which means
    a. you can use a much longer ICSP cable
    b. you can tolerate more types of circuitry on the ICSP pins, if they are shared.

2.Speed/complexity: PK2 software is simple and opens up close to instantly on my computer. And the software is more streamlined. The pk3 takes 3x as much clicking, even after the software loads and the device connects, which on my computer the pk3 software and hardware takes quite a bit of time to load and connect.

3.Reliability: PK2 is reliable and simple enough I have one built into my bench, pretty hard to access, glued underneath my bench somewhere. It's just plugged in at all times, 24/7. (And due to the ICSP drive and capacitance tolerance, the ICSP cable can be like 2 or 3 feet long). In 5 years it has only lost connection once. I can't even remember what plug to unplug/replug to cycle the power, so I just rebooted my computer. The PK3 is like a bad router that will have to be restarted on occasion. It is buggier. Even in P2G mode, I expect if I flash 100 chips, I will have to reboot the PK3 a few times. If I have to reboot the PK2 in P2G mode 1 in 1000, it's a shock. And the PK2 boots up in P2G mode in about half a second. The PK3 takes 5 or 6 seconds to reboot after a power cycle. Ironically, the type of issue the OP has posted about, this is what I expect with PK3, not PK2. There are many times, for instance, where PK3 will fail to update a chip. And it will also corrupt the previous flash, in the process. But hook it to the computer, and it works fine. I've even had it once verify a protected flash, but it left the code data unprotected.

PK3 is almost better compared to ICD3. The only thing it has in common with PK2 is name, form factor, and P2G. (And standalone software, if you want to include that failed (IMO) experiment). In terms of hardware, software, integration, support, debugger, it is a cheaper ICD3 and it compares very well, considering the cost and form factor. It is almost as fast as the ICD3 in debugging (although I don't use debugger but quite rarely). And compared to ICD3, the boot speed, the bugginess, and software interface is essentially the same, once you finally get the PK3 working (which can take a bit of initial fiddling). To be honest, I'm not even sure what features/devices the ICD has which the PK3 does not. I have all 3 of these programmers, and I have not yet had an occasion to pull out the ICD3 since getting a PK3.

If PK3 works fast and reliably on your computer system and you use MPLAB, and you do only dev and one-offs, then there's no reason to wonder. Just use the PK3. If you have any issues and you use devices supported by PK2, particularly in any sort of support role in a production/high quantity type environment, the PK2 has many advantages. And for $20 or $30.00, there is no reason not to have both. The question is... do you really need an ICD3, anymore?

If they had called it the "ICD-Lite", or something like that, and marketed is as an entry level ICD3 with full support and cross platform software, the response would perhaps have been overwhelmingly positive. Another part of the initial backlash was likely due to the buy-back program. Everyone who owned a PICKit2 received an offer for 50% off a PK3 if you send it back. They know you bought it, otherwise they wouldn't be sending you the offer. They could have just given you a discount on the PK3. (What are they going to do with used PICKit2's?) When you take this into consideration, along with the decision to ride on the name and form factor of the PK2, this sets up the PK3 for fail. It better do everything the older one does. And it better work out of the box... at least after following some official instructions. And it better be an nicely thought out interface. I bet you no one cared about the improved overcurrent protection and the multiple warnings added to the software interface. If anything, that part moved in the wrong direction. If the device is dangerous/expensive, that is up to me to make sure I don't brick it when I attempt to ICSP. I don't need popups (which, by the time I actually could have used a warning, I'll probably automatically click the wrong thing by habit, anyway). I have a computer to do things for me. Not to waste my time and attention to make me hit dialog buttons like a trained pigeon.

But if they hadn't wrapped "PICKit" all over this programmer, it might not have sold as much.