Debugging 16f88 programmer

I have a 16f88 programmer (of my own design) that was working quite well until recently. For some reason now, the MCU just decided to stop responding. By this I mean, when I enter into "read data" mode and pulse the clock, nothing happens on the data pin.

My programming circuit is very simple: two pins from the parallel port go into an inverter. The inverted signal goes to RB6 and RB7 of the 16f88 (the clock and data pins during programming mode). A third pin goes to a transistor that switches on the 12V source (for the MCLR pin on the 16f88). All three pins are controlled by a c++ program I wrote. I also have a 4th pin of the parallel port connected through the inverter to RB7. This pin is for reading the bits of memory when in "read data" mode.

Like I said, this setup was working great before. I was able to program a hex file into the chip and have it read the memory values back to me. Now that it's stopped working, I've worn my multimeter probes thin doing voltage and continuity checks. I even slowed the program way down and put LEDs on RB6 and RB7 to watch the 0's and 1's going into the chip. The circuit seems to be doing exactly what it's supposed to. I've ruled out the parallel port pins of being faulty. And all of my voltages look good (5V circuit power, ~4.5V on all the pins on the parallel port, ~4.5V signals from the inverter, 12V for the MCLR pin). The breadboard does not seem to be at fault either.

I have two 16f88's and I've tried both in the circuit. Still, I cannot rule out that I've managed to fry both of them. Is there a quick method to determine whether the chips are even alive anymore? Any other troubleshooting ideas?

Thanks in advance!
-Dan

Hi,

Well an unusual project so hows about an equally unusual answer.

If its a nice sunny day over there were the workers will be taking their lunch breaks on the grassy areas outside, why not nip down to Chandler and see if the Microchip guys can help.

Try posting the circuit so we can check it out.

However, unless the circuit (and software) is correctly designed, if you happen to enable the internal oscillator then you can't access it after that.

Nigel Goodwin said:

Try posting the circuit so we can check it out.

However, unless the circuit (and software) is correctly designed, if you happen to enable the internal oscillator then you can't access it after that.

Click to expand...

Nigel! That's precisely what I did right before everything went wrong. I guess I didn't do enough homework before jumping into a project. Setting the internal oscillator seemed innocuous to me, as my project wasn't timing critical and I didn't want to deal with extra crystal/resonator circuitry.

So how bad did I mess things up? I suppose I'll be reviewing the programming specification file tonight after work.

Wp100 said:

Hi,

Well an unusual project so hows about an equally unusual answer.

If its a nice sunny day over there were the workers will be taking their lunch breaks on the grassy areas outside, why not nip down to Chandler and see if the Microchip guys can help.

Click to expand...

Ha, I've considered it before . I actually have a friend that works at the Chandler site, but he's on the analog side. Not much of a digital IC guy.

Now wouldn't that be something... if Microchip had a walk-in troubleshooting service on site.

I reviewed the reference guide and the programming spec on the 16f88 and I'm still a little confused. The best understanding I've come to is that the program I installed on the PIC is self-starting now since it's using the internal oscillator. Therefore, my programming circuit is "fighting" with the internal control of RB6 and RB7 during my attempt to reprogram. But still, shouldn't the PIC give up control of those 2 pins when I raise the MCLR pin to Vihh (+12V)? I thought that put the PIC into a cleared-and-ready-to-be-programmed state.

Rusttree said:

Nigel! That's precisely what I did right before everything went wrong. I guess I didn't do enough homework before jumping into a project. Setting the internal oscillator seemed innocuous to me, as my project wasn't timing critical and I didn't want to deal with extra crystal/resonator circuitry.

So how bad did I mess things up? I suppose I'll be reviewing the programming specification file tonight after work.

Click to expand...

You messed it up because you can only enter programming mode if the PIC isn't running - there are various ways to prevent this. One way is to set MCLR to 13V BEFORE you switch Vdd ON. The other way (and the way I did it) is to switch MCLR to 13V VERY quickly after switching Vdd ON - there a certain startup time for a PIC to begin running, and it's easily long enough to get MCLR high after Vdd. If your programmer doesn't switch Vdd you're a bit stuffed , but an alternative is if you have FULL control of MCLR, and can switch it LOW, Vdd, or 13V - bringing it LOW stops the oscillator (assuming MCLR isn't used as an I/O pin), then switching it to 13V from LOW enters programming mode long before the oscillator can run.

And then put a bootloader on it so it never happens again.

upand_at_them said:

And then put a bootloader on it so it never happens again.

Click to expand...

No point if you have a programmer.

But with a bootloader you only "program" it once. When you change the code you're only using the serial connection. If you have a finnicky programmer you'd be dealing with it all the time.

upand_at_them said:

But with a bootloader you only "program" it once. When you change the code you're only using the serial connection. If you have a finnicky programmer you'd be dealing with it all the time.

Click to expand...

Then buy or build a decent programmer.

blueroomelectronics said:

Then buy or build a decent programmer.

Click to expand...

I don't know the OP's circumstances, I was just trying to be helpful. "Just spend more money" isn't always an option for some. I find the bootloader very handy.

Nigel Goodwin said:

One way is to set MCLR to 13V BEFORE you switch Vdd ON. The other way (and the way I did it) is to switch MCLR to 13V VERY quickly after switching Vdd ON - there a certain startup time for a PIC to begin running, and it's easily long enough to get MCLR high after Vdd. If your programmer doesn't switch Vdd you're a bit stuffed , but an alternative is if you have FULL control of MCLR, and can switch it LOW, Vdd, or 13V - bringing it LOW stops the oscillator (assuming MCLR isn't used as an I/O pin), then switching it to 13V from LOW enters programming mode long before the oscillator can run.

Click to expand...

Well I thought for sure this would make it work. I hooked up Vdd to a parallel port pin through a transistor and I modified my code to switch Vdd on and then immediately switch on MCLR (~12.2V). As a simple test, I issue the "load configuration" command (PC to 0x2000) and read data at that address. I'm getting nothing in return. RA7 just sits are 0V for every clock cycle during the read. I really don't think it's actually getting into programming mode at all. I've also tried setting MCLR high to begin with, then switching on Vdd, then sending MCLR low and quickly high again. No difference.

Unfortunately, my last successful programming set the internal oscillator with regular port I/O function... so I can't use RA6 to tell if the internal osc is actually really running or not.

I'm really stumped. Any other debugging suggestions to throw at me? What I would like most is if there's some rudimentary way of determining whether the PICs are actually still alive. There's still a possibility I've fried both of them, but I can't tell.

You need a programmer that supports VPP before VDD.

blueroomelectronics said:

You need a programmer that supports VPP before VDD.

Click to expand...

I did try that. I set MCLR high, turned on Vdd, and then cycled MCLR quickly - as fast as my parallel port could cycle the pins. Still no joy.