Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Strange PICkit 2 problem - can't program

Status
Not open for further replies.
Well that was a good (but horribly time consuming) lesson. The details are on my site if you want to see.

Who'd of thunk that once you set Timer1 to use a crystal you can't reprogram the chip without erasing it first. And you can't erase it with MPLAB. Weird! :p

EDIT: My 1000th post!

If you connect to a working chip then swap in the bad one you can erase it from MPLAB. We ran into the same problem in class but noticed the problem followed the chip. You could have seen this if you had switched to a simple program to test your chips and PICkits.

Live and learn.
 
If you connect to a working chip then swap in the bad one you can erase it from MPLAB. We ran into the same problem in class but noticed the problem followed the chip. You could have seen this if you had switched to a simple program to test your chips and PICkits.
Great idea, but by the time I got this even partly figured out I had screwed up all three 16F88's that I have here. :p I just had no idea it was the program. The problem looked so much like hardware.
 
Last edited:
Great idea, but by the time I got this even partly figured out I had screwed up all three 16F88's that I have here. :p I just had no idea it was the program. The problem looked so much like hardware.

I agree that it does look like a hardware problem. The lesson here is not to jump to that conclusion. When things go wrong step back to a known good working setup for test. As you found out the code under development, should not be used as a part of that test.
 
I think it has to do with the 16F88!!

I had the same problem when trying to program an F88.

I thought I accidentally connected power wrong and fried the programmer so Ichecked wiring and tried my backup PK2 that I use as UART and analyzer and it didnt work either. Tried a new F88, notta, zilch, nothing!!!

Then I thought It was my compiler, but after trying for hours to fix it I tried a 628A, 18F4525 and a few others and got nothing out of 2 different PicKit2's using V2.5.

The next day I tried it on my 18F4525 dev board and it worked fine. I did nothing that I know of to fix the issue. Tried an F88 and it identified the chip the first time, thought everything was OK until I went to program the F88 and boom, back to nothing.

Fiddled around for a wile and it started working again.

I think the F88 is messing up the PicKit 2 driver somehow.

It works fine on all other chips I use.

I will try an F88 again in the next few days to see if it does it again to confirm.
 
I think it has to do with the 16F88!!

I had the same problem when trying to program an F88.

I thought I accidentally connected power wrong and fried the programmer so Ichecked wiring and tried my backup PK2 that I use as UART and analyzer and it didnt work either. Tried a new F88, notta, zilch, nothing!!!
I've solved the problem. It was caused by me enabling Timer1 to use a crystal on the PGD/PGC pins. Once that's programmed into the chip and running, the programmer can no longer identify the chip (I assume) because the pulses Timer0 is outputting on PGD/PGC interfere with the programmer trying to use the same pins.

The cure is to use the PICkit 2 software (with target power off) to ID and erase the chip. It won't ID it with target power on (pulses too strong??). Then I shut that off and can ID and program normally from MPLAB.
 
Last edited:
I've solved the problem. It was caused by me enabling Timer1 to use a crystal on the PGD/PGC pins. Once that's programmed into the chip and running, the programmer can no longer identify the chip (I assume) because the pulses Timer0 is outputting on PGD/PGC interfere with the programmer trying to use the same pins.

The cure is to use the PICkit 2 software (with target power off) to ID and erase the chip. It won't ID it with target power on (pulses too strong??). Then I shut that off and can ID and program normally from MPLAB.

Great Futz,
At last you came out of the riddle and now things are normal

a good experience of how not....
 
I just read **broken link removed** that explains the perfect cure for the problem I was having. Simply put a delay at the beginning of the code so it doesn't start the crystal up right away. That allows the programmer to get control before the clock starts up and prevents it. Knowing that would have saved me a bunch of time. :p
 
There is one more thing to watch for which I stumbled upon recently.

When I power target from PICkit2 and target has a Vdd filter cap (I was using 330uF), it locks the PICkit2 application. I believe it is because it temporarily drops the USB voltage (if you look in PICkit2 schematic, you see there is no protection against that) and resets PICkit2.

The cure was to power target from it's own supply.
 
I've noticed the same thing with the Junebug, the PICkit2 pulls target VDD to GND (5mA) if the target sags it assumes the target is not powered. Then it turns on a P-Channel FET pulls it to VDD, if the VDD rises too slowly it'll stop applying VDD to keep from killing the P-FET.
 
There is one more thing to watch for which I stumbled upon recently.

When I power target from PICkit2 and target has a Vdd filter cap (I was using 330uF), it locks the PICkit2 application. I believe it is because it temporarily drops the USB voltage (if you look in PICkit2 schematic, you see there is no protection against that) and resets PICkit2.

The cure was to power target from it's own supply.
Such high value Filter caps are not needed unless we use main operated adopters. even then the adopter/wall wart would have built-in filtering. for normal DC power supply from batteries, such value may not matter. In case of USB derived power, i read somewhere that a nominal 1uF and a 0.1uF disc or MLC capacitor combination would suffice.
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top