Dodgy 12F675?

[Pete Smith]

Hi all.

I've been doing some work on PIC12F675's recently.

I bought 5 of them about a fornight ago. Within a couple of hours, 2 of them had died, and there's now another one dead.

"Died" means that it programs and verifies 100\%, but when you actually plug it in & give it power, it does absolutely nothing.

Are these little 8 pin PICs a lot more delicate than the 18/28/40 pin PICs? I've "managed" to kill one or two PICs in the past, but this is a record, killing 3 in a fortnight.

TBH, I'm not even sure if the 2 that died ever worked 100\% from the offset.

What appears to happen just before they die is that I was testing interrupt code (wake up on change). When a change occurs, an output toggles. The first sign of something going wrong is rather than toggling 0v 2.8v 0v 2.8v is that the output that's being driven goes 3v 2.8v 3v 2.8v. Shortly after this, everything will stop working.

Have I been doing something stupid? (I'll admit to my workstation not being 100\% static sensitive device friendly, but it's never done anything before).

Thanks,

Pete.
___________________________
This message was ported from CCS's old forum
Original Post ID: 144516424

[john cutler]

Are you setting CMCON to 0x07? I had output level wierdness with forgetting to set the comparators off when not using them. It was a while ago, so I can't remember the exact specifics, but it's worth checking.

good luck!

JC
___________________________
This message was ported from CCS's old forum
Original Post ID: 144516435

[jpt@tayloredge.com]

My first experience with the 12F parts was the way the on board RC oscillator was cal'd: They put the cal value (From the silicon fab) in the last program memory location and do a [call (lastlocation)] + [retlw (calvalue)]. The first location in rom in PICC is the call and the value returned is writen to the osc cal. If you ever do a bulk erase on the part (which you may do on a flash device), the cal value turns into a non-retlw opcode and the device just sits looping between the first and last instructions... look at your asm-list after a compile and see if there is a call(lastromadrress) near the beginning. If there is, you need to save that value and use a #rom to jam it into the upload!!
___________________________
This message was ported from CCS's old forum
Original Post ID: 144516449

[Pete Smith]

:=Are you setting CMCON to 0x07? I had output level wierdness with forgetting to set the comparators off when not using them. It was a while ago, so I can't remember the exact specifics, but it's worth checking.

ADCON0 = 0;
ANSEL = 0;
CMCON = 7;

I found this out _very_ quickly :-)

Of the 5 PICs I bought, the code originally worked on 3 of the 5 (the other 2 wouldn't even wake up).

Now, the code only works on 2 of the 5.

Very odd.

Thanks for the pointer though :-)

Pete.
___________________________
This message was ported from CCS's old forum
Original Post ID: 144516460

[John Yaron]

:=Hi all.
:=
:=I've been doing some work on PIC12F675's recently.
:=
:=I bought 5 of them about a fornight ago. Within a couple of hours, 2 of them had died, and there's now another one dead.
:=
:="Died" means that it programs and verifies 100\%, but when you actually plug it in & give it power, it does absolutely nothing.
:=
:=Are these little 8 pin PICs a lot more delicate than the 18/28/40 pin PICs? I've "managed" to kill one or two PICs in the past, but this is a record, killing 3 in a fortnight.
:=
:=TBH, I'm not even sure if the 2 that died ever worked 100\% from the offset.
:=
:=What appears to happen just before they die is that I was testing interrupt code (wake up on change). When a change occurs, an output toggles. The first sign of something going wrong is rather than toggling 0v 2.8v 0v 2.8v is that the output that's being driven goes 3v 2.8v 3v 2.8v. Shortly after this, everything will stop working.
:=
:=Have I been doing something stupid? (I'll admit to my workstation not being 100\% static sensitive device friendly, but it's never done anything before).
:=
:=Thanks,
:=
:=Pete.

I've had 2 18F8720's that did the same thing... however,
they never worked in the first place... they'd program
without any errors, but, not execute the code properly.
They DID NOT just vegitate.

I wouldn't disregard the possibiltiy of faulty chips (even
though uChip mgt claims they peerform impeccable manufacturing
and blame us,.. who spend 12 hours a day working with it
... classis mgt political campaign lies)
___________________________
This message was ported from CCS's old forum
Original Post ID: 144516469