Pickit 2 not recongnizing pic16f88, but kitsrus does.

[dr pepper]

I have both the above programmers, and a selection of 16f88's, only one of the 16f88 works with the pickit 2, all the others the pickit just reports 'device id not as expected', and the pickit will not program them.
All the pic16f88's program and run the code perfectly when I use my kitsrus programmer.
Both are usb data and power.
Is this some silly fuse thing again.

 

[tunedwolf]

It's a common issue when the security fuse is blown on the PICPro style programmers. Blank the devices and remove any security locks in your kitsrus and then try with the device in the pickit Sometimes the only way to get the device straightened out again is to breadboard a wee programmer circuit and program another device to run the blank sequence on the dodgy devices. At least that was my early experience with the PIC and suspect programmers

 

[dr pepper]

I've programmed lots of devices but never had that.
I have tried blanking th edevice on the pickit, didnt work, however I have not tried a blank on the kitsrus, I'll try that and see what happens.

 

[dr pepper]

Ok so this has become a pain.
I have put every pic16f628a and pic16f88 I have (about 20) in my kitsrus programmer and erased them, program memory, data memory and fuses.
Then if I put them in the pickit2 its happy and will program them, but if I then either try to verify the code or re0program them the pickit tells me it doesnt recognize the chip.
My programs have the data and program code protect off.
If I program the chip with the pickit after erasing it with the kitsrus first and then put the chip in the application it runs the code, so the pickit does program the devices, but only if they are erased first.
Reading the chip with the kitrus after the pickit has progammed it confirms that the code protect bits are disabled.
Thepickit does sometimes come up with a low supply voltage and low programming voltage warning, so I'm suspecting its dying.
The only other change is that I'm using a zif socket addon for the pickit instead of icsp, I have however used the zif socket before without this trouble.

 

[tunedwolf]

I know that all of the earlier parallel type programmers used to mess up the fuses and device ID, well perhaps not all, but all of the ones I tried, but the blank always seemed to work properly on them. That's why I suggested blanking them with the kitsrus one first. Breadboard up an ICSP and test a device that programs but doesn't verify just in case it's a cable length/ capacitance issue with your ZIF board

 

[Pommie]

I've had this problem problem before and it was caused by a combination of things. They are the internal oscillator and timer 1 with an external crystal. What I think happens is that the pic starts to run and the programming pins get set to use the external crystal and so it won't program. Is there some test you can do to to distinguish if it's in your board or not and only enable timer1 if it passes the test? One other way around the programming problem is to put a good pic into PK2 and after it find the chip swap it just before programming - the PK2 tries to read the ID before the programming voltage is applied and this is the step that fails.

Let us know how you go.

Mike.

 

[dr pepper]

Pommie, that makes a lot of sense, this project does actually use timer 1 with an external xtal, that said I've done lots of projects with timer 1 and an xtal without issues before.

What I'll do is clear the bit temporarily that enables timer 1's external osc in my code then blow the chip and see if it'll verify, then I'll know if its the timer1 issue or not.

I'll also try the same in breadboard, maybe theres something odd going on in the zif adaptor as allready pointed out.