Originally Posted by nickelflippr

You did run the Pickit 2 ->Tools->Troubleshoot right?

I hadn't done that. Just did it and it passed every test perfectly. My new multimeter even has Hz measurement, so I could confirm the 30kHz thing.

When I started up the software and did a comm check, it did just what was happening before - with target power on, the chip was not detected. With target power off, it was.

While tinkering with the PICkit software I did a full erase of the chip. I also looked at every other available thing in there just in case there was something that would fix my problem.

I shut that off and went back to MPLAB and now it works fine! Maybe the erase fixed it? I don't know exactly what cured it, but it seems good now... Wonder what all that was about? Weird.

EDIT: False alarm. It's still screwed up.

OK, it's my program. Must have made a change to the config bits, though I don't remember doing so. I don't see anything wrong with them, but I erase the chip with the PICkit software and can then detect the chip both with and without target power.

But after reprogramming the chip with my program I can't detect the chip with target power on, but CAN detect it with target power off.

Here's my program's config line:

Code:

#pragma DATA _CONFIG, _WDT_OFF & _INTRC_IO & _LVP_OFF & _MCLR_ON

And I narrowed it further. It wasn't config bits. I had been messing with Timer1. I had previously set it to expect a clock source on the PGD/PGC pins (I knew it couldn't be programmed with the crystal plugged in, and it had been removed), but I was sure I had disabled that. Guess I was mistaken, because when I comment all Timer1 code out, I can program the PIC and everything still works.

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!

EDIT: My 1000th post!

Originally Posted by futz

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!

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.

Originally Posted by Pommie

a similar thread but the consensus was that this couldn't happen.

Well I beg to differ! I put in the hours to debug the stupid thing. It was interesting though, and I don't mind wasting hours as long as I learn something good out of it.

Originally Posted by 3v0

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. I just had no idea it was the program. The problem looked so much like hardware.

Originally Posted by futz

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. 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.

Originally Posted by Sputnik

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.

Originally Posted by futz

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 an article 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.

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.