Do PIC pins just... die?

Did you remember to clear ANSEL?

Output pins can be killed.

When using MCLR as an I/O pin, it only works as an input.

I've never used a 16F88, but I did teach myself to program 17-series PICs some years ago (back when the 17 series was the latest and allegedly greatest, naturally).

It sounds as though there's a configuration register that you aren't setting up properly in your startup code--i.e. some of your 'outputs' are programmed to be inputs.

Cheers,

Phil Hobbs

Well, don't you win the Helping Hand award for the evening? This immediately fixed all problems _except_ RA5/Vpp/!MCLR. Still trying to figure out that one, though...bit 5 of CONFIG1, MCLRE, is cleared, so RA5 is supposed to be I/O. I even ran a version of the test with that bit set, and it ended up not running unless set high (as expected).

So, there's apparently nothing physically wrong with the pin itself, but I'm not entirely sure about what's behind it. Do you think there is anything else I ought to check?

Thanks a zillion PSM

I just caught this one. Never mind... Jeez, they really need to be louder when they say some of their pins are input-only!

All right, so my chips are working as intended, and I don't have to go to bed worried. Thank you!

PSM

The other one that catches a lot of people, is AN4, which on many of the slightly larger PICs, is an 'open collector' style output (pull down only...).

The permutations and variations on PIC pins, is one of the 'delights', of this product...

Best Wishes

No. I'd take a nap or go watch TV or have a drink or something and come back a few hours later and triple-check my wiring. :-)

Good Luck! Rich

OK, Anthony solved it for you - but now my advice is even _more_ applicable - while taking your nap or watching your show, you don't have to fret about getting the thing running. ;-)

Cheers! Rich

"Peter S. May" skrev i en meddelelse news:qeadncmesofGlD3bnZ2dnUVZ snipped-for-privacy@comcast.com...

Apart from the other good advice, check the stepping number on the chip. I.e: "it worked before, now it does not" or "it works in the programmer and on the bench, not in the Job".

I had major strangeness because of changes between revisions of silicon that required updates to the programmer ;-)

One of the most irritating debugging sessions I experienced was with a PIC that I had bought (a few pieces for development) 8 months or so earlier. When we actually got around to finishing the development there were persistent issues one of the peripherals. I finally narrowed it down to a silicon bug, but Microchip had already eliminated all traces of the errata from that stepping from their website, and I had not archived the errata and datasheets since it wasn't in production. One of the earlier errata was still floating around the net (on a University website).

Best regards, Spehro Pefhany

I had a similar episode some years back. I was pulling my hair out trying to get an 8051 variant to wake up on interrupt. It simply wouldn't. It got to the point that I was calculating battery life with the processor constantly running (it was a CMOS variant) and trying to figure out how to squeeze enough elsewhere to make the budget. Seeing my frustration my boss asked if he could help. Sure, here's the databook, handing him a new one off the shelf. Next day he comes in pointing at a paragraph describing pretty much my problem, but saying that it was too obvious. "Wait just a minute!" "That paragraph isn't in my copy!". My dog-eared and marked-up copy was slightly older and didn't have all the secrets of the brew.

Don't these companies have an application support engineer that will answer such questions? Seems that it might have saved time...

Sparky

I have found it useful to get the name of the first competent guy you find, then call him directly.

Or just figure it out myself, because as you said the front line is pretty unhelpful.

Whenever I've done that I've found the people you can contact easily tend to be less knowledgable than I am-- junior engineers who have a very shallow knowledge of a lot of products, and are capable of dealing mostly with questions that should not have been asked in the first place (sort of gatekeepers). Eventually, if you persist, and have the time to work at it, you can usually drill down to someone who knows a lot, but it might take days, and even they may not be entirely candid with you if it looks like something that's their fault.

There are probably some designers who develop a relationship with the FAE for a particular product line and use it for hand-holding through the process, but I suspect most of us don't (and perhaps can't) work that way.

Best regards, Spehro Pefhany

They will answer if you find someone who knows. We had direct contacts but none were of any practical help. "Should work" isn't help.