Searching \ for '[PIC] fried 16F88?' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=16F
Search entire site for: 'fried 16F88?'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] fried 16F88?'
2005\08\18@140556 by Rob Hamerling

flavicon
face

After having programmed a 16F88 several times succesfully, all of a
sudden it refuses to be reprogrammed and erased. It doesn't even return
its device-ID (via the Wisp628 I see '3FFF').
I didn't change any hardware, only the program (not the config word).
I moved the chip to anoterh board but it keeps this behaviour, while
other chips work fine (I tried only a read!) on both boards.

Maybe important: I have set RA5/MCRL to digital I/O (bit 5 of the config
word is 0). But I don't think this chip has the 'Vpp-before-Vdd'
requirement (I didn't read it in the programming specs). Anayway
reprogramming worked fine before without it. Nevertheless I inserted
Wouters 'dongle' between Wisp628 and target board, but that made no
difference.

Is it possible to hurt a (16F88) PIC by reprogramming such that it dies,
or at least behaves like it is dead?

I don't want to kill more 16F88s, so I didn't try another one yet.

Regards, Rob.


--
Rob Hamerling, Vianen, NL phone +31-347-322822
homepage: http://www.robh.nl/

2005\08\18@142744 by Stef Mientki

flavicon
face

> Is it possible to hurt a (16F88) PIC by reprogramming such that it
> dies, or at least behaves like it is dead?
>
Rob, try it tomorrow again !
I've seen this kind of behaviour with JDM programmer and 16F628,
after reprogramming it for about 10 or 20 times within a few hours,
I had to wait one day to get access to these PICs again.
But I guess I'm about the only one in the whole world who has seen this
fantastic phenomena ;-)

cheers,
Stef

>

2005\08\18@143710 by olin piclist

face picon face
Rob Hamerling wrote:
> Is it possible to hurt a (16F88) PIC by reprogramming such that it dies,
> or at least behaves like it is dead?

Plugging it in backwards could do that.

*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\08\18@145807 by Rob Hamerling

flavicon
face


Olin Lathrop wrote:
> Rob Hamerling wrote:
>
>> Is it possible to hurt a (16F88) PIC by reprogramming such that it dies,
>> or at least behaves like it is dead?
>
>
> Plugging it in backwards could do that.

Want to be funny? Other possibilities I did NOT ask about: feeding it
with 230VAC, hitting it with an axe, heating it to 1500 degrees C, etc.

I didn't remove the chip from the board or made any other hardware
changes.... could you answer the real question, please?

--
Rob Hamerling, Vianen, NL phone +31-347-322822
homepage: http://www.robh.nl/

2005\08\18@150946 by Wouter van Ooijen

face picon face
> Rob, try it tomorrow again !
> I've seen this kind of behaviour with JDM programmer and 16F628,
> after reprogramming it for about 10 or 20 times within a few hours,
> I had to wait one day to get access to these PICs again.
> But I guess I'm about the only one in the whole world who has
> seen this
> fantastic phenomena ;-)

I sure never have seen this.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\08\18@151643 by Lee Jones

flavicon
face
>>> Is it possible to hurt a (16F88) PIC by reprogramming such that
>>> it dies, or at least behaves like it is dead?

>> Plugging it in backwards could do that.

> Want to be funny? Other possibilities I did NOT ask about: feeding it
> with 230VAC, hitting it with an axe, heating it to 1500 degrees C, etc.
>
> I didn't remove the chip from the board or made any other hardware
> changes.... could you answer the real question, please?

I think Olin's response was reasonable.

In your original message, you said

# After having programmed a 16F88 several times succesfully, all of a
# sudden it refuses to be reprogrammed and erased. It doesn't even return
# its device-ID (via the Wisp628 I see '3FFF').
# I moved the chip to anoterh board but it keeps this behaviour,

You did not state what package (DIP versus surface mount) you were
using nor what style of programming (ICSP or ZIF socket).  So you may
have to remove/reinsert the chip for each programming cycle.  How are
we (PIC list members) to know?

And you did state that you had moved the chip to another board.  This
implies you are using a DIP package.  If so, it's quite possible that
you had plugged the chip in incorrectly.  Certainly not something to
rule out a priori.

                                               Lee Jones

2005\08\18@153330 by Stef Mientki

flavicon
face


Wouter van Ooijen wrote:

{Quote hidden}

Yes, you're one member of the rest of the world.
btw, I certainly didn't want to insinuate that wisp is as "bad" as JDM ;-)
btw2, I even don't want to insinuate that JDM is "bad" !

Stef

>Wouter van Ooijen
>
>-- -------------------------------------------
>Van Ooijen Technische Informatica: http://www.voti.nl
>consultancy, development, PICmicro products
>docent Hogeschool van Utrecht: http://www.voti.nl/hvu
>
>
>  
>

2005\08\18@162555 by Jan-Erik Soderholm
face picon face
Rob Hamerling wrote :

> I have set RA5/MCRL to digital I/O...

OK, so the PIC "runs" as soon as Vdd is applied.

The Prog Spec says :

"Note: The Osc must not have 72 osc clocks
while the device MCLR is between VIL and
VIHH."

And also :

"Note: The MCLR pin should be raised from
below VIL to above the minimum VIHH
(VPP), within 250 µs of VDD rise."

(Or simply appying Vdd *after* Vpp.)

I thought that enabling internal-
MCLR
on *any* PIC also implied this requriment
in timing between Vpp and Vdd.



> I inserted Wouters 'dongle' between Wisp628 and
> target board, but that made no difference.

Not that the dongle must be able to *fast* short
Vdd to GND and also fast release Vdd again.

So you can't have to many uF's on the
breadboard.

A "few" uF's usualy works for me.

You can't power the curcuit with something that
can't be shortet to GND. A 7805 or 78L05
i usualy OK.

Some bench-labb-power-
supplys have
"slow start" after a short. That does not
work.

I've use the dongle with success and also
one of my Wisp628 customers that locked
himself out from a 12F.

What you see is exectly this, you can't get the device
into programming mode, and the Wisp628
can't "see" it at all.

So, try the dongle again. Be carefull with your caps
on the breadoard.

Jan-Erik.


2005\08\18@194409 by olin piclist

face picon face
Rob Hamerling wrote:
>> Plugging it in backwards could do that.
>
> Want to be funny? Other possibilities I did NOT ask about: feeding it
> with 230VAC, hitting it with an axe, heating it to 1500 degrees C, etc.
>
> I didn't remove the chip from the board or made any other hardware
> changes.... could you answer the real question, please?

I don't owe you anything, and you should keep in mind that you're the one
asking for free help.

And, I was serious about my comment.  Anyone who has plugged enough chips
into sockets has plugged a few of them in backwards.  I've done it with
PICs.  The few times this has happened, I have noticed they got really hot.
It's not hard to imagine the PIC might not respond as specified to
programming commands (or anything else) after that.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\08\18@195517 by John Nall

picon face
Olin Lathrop wrote:

> > I don't owe you anything, and you should keep in mind that you're
> the one
> asking for free help.
>
> And, I was serious about my comment.  Anyone who has plugged enough chips
> into sockets has plugged a few of them in backwards.  I've done it with
> PICs.  The few times this has happened, I have noticed they got really
> hot.
> It's not hard to imagine the PIC might not respond as specified to
> programming commands (or anything else) after that.

As brusque as Olin can sometimes be with his comments, he is 100%
correct on this one.  It was a reasonable response to an ambiguous
question.  If you can't stand the heat, then stay out of the kitchen.

2005\08\18@200931 by Mauricio Jancic

flavicon
face
I've found, specially with the 16F84 in some beginner projects that most of
the times the PIC can be connected backwards with no apparent* damage.
However, if you connect it 1 pin upward or downward, the chip don't work any
more...

Just a coment...

*note that the apparent is a very important point. Sometime you just cant
see or detect the damage at first sight.

Mauricio Jancic
Janso Desarrollos - Microchip Consultants Program Member
spam_OUTinfoTakeThisOuTspamjanso.com.ar
http://www.janso.com.ar
(54) 11 - 4542 - 3519
{Original Message removed}

2005\08\19@000018 by Jinx

face picon face
> Is it possible to hurt a (16F88) PIC by reprogramming such that
> it dies, or at least behaves like it is dead ?

I vaguely recall having a PIC some years ago that wouldn't take a
program temporarily, but it came around before I could discover
why

As for the F88 specifically, I've had them in and out of a PIC
Start Plus and reprogrammed them with ICSP numerous times
in long sessions and never had your problem. If it's a particular
one that's doing it, maybe put it aside and use another. If the
same thing happens again then perhaps you're on to something.
Not nececelery with the F88 but possibly with your programmer,
power supply or board

On rare occassions a PIC's gone into a socket backwards, once
even with 12V on it when I used the wrong PSU, but I've found
that doesn't always do them in. Often they appear to be fine. My
experience is that usually they die unexpectedly during development
for some unknown reason. Could be static, could be a funny glitch
goes through them. It always seems to be something unrepeatable
in my case. Fortunately I'm generally kind to my PICs and they
don't turn up their pins that often

2005\08\19@020127 by Lindy Mayfield

flavicon
face
When I first started and knew no thing about electricity I read something about a pull up and tied my MCLR directly to the +5 rail.  That screwed it up for a while, but it came back.

{Original Message removed}

2005\08\19@034040 by Jan-Erik Soderholm

face picon face
Jinx wrote :

> As for the F88 specifically...
> reprogrammed them with
ICSP numerous times...

With internal-MCLR **enabled** ?

That is the
key point here...

Jan-Erik.



2005\08\19@041358 by Rob Hamerling

flavicon
face


Jan-Erik Soderholm wrote:
> Rob Hamerling wrote :
>
>>I have set RA5/MCRL to digital I/O...
>
> OK, so the PIC "runs" as soon as Vdd is applied.
>
> The Prog Spec says :
>
> "Note:
> The Osc must not have 72 osc clocks while the device MCLR is between
> VIL and VIHH."
>
> And also :
>
> "Note: The MCLR pin should be raised from
> below VIL to above the minimum VIHH
> (VPP), within 250 µs of VDD rise."
>
> (Or simply appying Vdd *after* Vpp.)

I was aware of this possible issue, therefore I mentioned it explicitly. But I read the datasheet differently, and the F88 datasheet doesn't contain a diagram like figure 2.2 of the 12F627/etc datasheet, which is very clear at this point.
BTW I don't understand how you can have 72 osc cycles before Vdd is applied.

Anyway I re-programmed the same F88 at least 20 times before, in the same setup without plugging/unplugging anything except power and without the Wisp628 dongle. And then suddenly without any (for me) apparent reason it behaves differently.


> I thought that enabling internal-
> MCLR
> on *any* PIC also implied this requriment
> in timing between Vpp
> and Vdd.

I thought it was not needed for the F88.

> Not that the dongle must be able
> to *fast* short Vdd to GND and also fast release Vdd again.
>
> So you can't have to many uF's on the breadboard.
>
> A "few" uF's usualy works for me.

I have no uF's at all, only 1 100nF.

> You can't power the curcuit with something that
> can't be shortet to GND. A 7805 or 78L05 i usualy OK.

That's what I use.

> What you see is exectly this, you can't get the device
> into programming mode, and the Wisp628 can't "see" it at
> all.

>
> So, try the dongle again. Be carefull with your caps
> on the > breadoard.

I just tried to re-animate the seemingly dead F88. First without dongle: no sign of life. So the suggestion of Stef Mientki didn't help!
Then I applied the dongle and now it does respond again and I could reprogram it!   I tried it last night in the same way, but maybe the working of the dongle isn't that consistent/reliable.
Now I can reprogram the F88 again even without dongle!!
However I don't have a comfortable feeling about it....

Regards, Rob.

-- Rob Hamerling, Vianen, NL phone +31-347-322822
homepage: http://www.robh.nl

2005\08\19@042357 by Rob Hamerling

flavicon
face


Olin Lathrop wrote:
>
>>> Plugging it in backwards could do that.
>>
>
> And, I was serious about my comment.  Anyone who has plugged enough chips
> into sockets has plugged a few of them in backwards.  I've done it with
> PICs.  The few times this has happened, I have noticed they got really hot.
> It's not hard to imagine the PIC might not respond as specified to
> programming commands (or anything else) after that.

Yeah, I did plug PICs backward myself too..
But the original question was: "Is it possible to hurt a (16F88) PIC by
reprogramming such that it dies, or at least behaves like it is dead?"
OK, maybe the description was somewhat ambiguous, but I meant it
literally: only re-programming. I mentioned 'Wisp628', which implies
ISCP and no plugging out/in.  The move to another board was only _after_
it seemed to be unprogrammable.
See also my reply to Jan-Erik for follow-up.
Thanks, Rob.


--
Rob Hamerling, Vianen, NL phone +31-347-322822
homepage: http://www.robh.nl/

2005\08\19@043941 by Wouter van Ooijen

face picon face
> I have no uF's at all, only 1 100nF.

I would suggest at least a 22u, within let's say 10 cm of the PIC.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\08\19@045005 by Stef Mientki

flavicon
face

>
>>
>> So, try the dongle again. Be carefull with your caps
>> on the > breadoard.
>
>
> I just tried to re-animate the seemingly dead F88. First without
> dongle: no sign of life. So the suggestion of Stef Mientki didn't help!

Rob,
I don't know what the dongle does,
but what else did you do, except waiting ?
Stef

>

2005\08\19@045027 by Jan-Erik Soderholm

face picon face
Rob Hamerling wrote :

> BTW I don't understand how you can have 72 osc
> cycles before Vdd is applied.

Not *before* Vdd (of course !).

*Between* Vdd and Vpp.


> I thought it was not needed for the F88.

You still have the "max 72
cycles before Vpp" issue.

That is hard to
meet if Vdd is
constatly on (and int-MCLR is
enabled).


> Then I
applied the dongle and now it does
> respond again and I could
reprogram it!

:-)

> Now I can reprogram the F88 again
> even without
dongle!!

With internal-MCLR *enabled* ?
If so, I'm a bit lost...

Jan-
Erik



2005\08\19@050328 by Jan-Erik Soderholm

face picon face
B.t.w, my Wisp628 customer who had
the same (or a similar) problem with
a 12Fxxx, had to power the PIC and the
Wisp628 with two different
7805's.

Sometimes the dongle will power down
the Wisp628 also, which
you don't
want, of course. :-)

Don't know why, maybe because he
built
his dongle using another transistor
the the one Wouter specifies, I
don't know...



Stef Mientki wrote :

> I don't know what the dongle
does,...

It momentarily shorts Vdd to GND, so you
can meet the
reqirements of
"Vpp before Vdd" when you have
int-MCLR *enabled*.

The
PICs (most of them ?) are not
allowed to start "running"before
Vpp is
applied.

With ext-MCLR that is a non-issue,
of course...

Jan-Erik.



2005\08\19@053047 by Wouter van Ooijen

face picon face
> BTW I don't understand how you can have 72 osc cycles before
> Vdd is applied.

The spec talks about the time between /MCLR logical high (so the chip is
released from reset) and /MCLR being at Vpp level (so the chip enters
programming mode). When too much time elapses between these two points
the chip start running. Apparently the programming hardware uses the
program counter, assumes it to be 0 on programming-mode-entry, without
resetting it.

This can of course only be an issue with the Vdd-before-Vpp sequence
(without the dongle), with Vpp-before-Vdd /MCLR is already at Vpp when
the chip is powered.

The F88 progspec is a bit peculiar, it indeed does not mention the
Vpp-first sequence, yet the /MCLR pin of the chip can be configured as
input, and it can be configured for internal oscillator. Maybe a
documentation error, or maybe this chip never needs the Vpp-first
sequence.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\08\19@053048 by Wouter van Ooijen

face picon face
> Sometimes the dongle will power down
> the Wisp628 also, which
> you don't want, of course. :-)
> Don't know why

because the Wisp628 + dongle should have a larger elco on the Wisp628
side for the Wisp628 to survive the 'shorting' period. (NB: this is
mentioned on the Wisp628 page!)

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\08\19@054355 by Jan-Erik Soderholm

face picon face
Wouter van Ooijen wrote :

> [ I wrote : ]

> > Sometimes the dongle
will power down
> > the Wisp628 also, which
> > you don't want, of
course. :-)
> > Don't know why

The "don't know why" was refering to
the
paragraph before the one you quoted.
My fault...

> because the
Wisp628 + dongle should have a larger elco...

*Should* ?

Your Wisp628
page  says :

"In some cases it might be necesarry to
add a bigger elco
on the Wisp628..."

In any case, the dongle you built end
sent me,
works just fine as-is without
any additional elco...

Regards,
Jan-Erik.



2005\08\19@055840 by Jan-Erik Soderholm

face picon face
Hi again...

I've run few test with a F88.

I used b818-1.hex and b818i-
1.hex from
Wouters blink-a-LED page.

Both re-programs fine on a F88...

B818i-1.hex is supposed to use
both intosc and int-MCLR.

I expected
b818i-1.hex
to show the reprogramming
issues of other int-MCLR chips...

I'm as lost as usualy... :-)

Regards,

Jan-Erik.





2005\08\19@055909 by Wouter van Ooijen

face picon face
> In any case, the dongle you built end
> sent me,
> works just fine as-is without
> any additional elco...

This will depend on a lot of factors
- the exact value of the 5V
- the exact value of various components (elco's can often be +50%!)
- the exact Vdd level where the 16F628 in question stops working (might
be different for 16F628, 16F628A, 16F648A).

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\08\19@060540 by Rob Hamerling

flavicon
face

> Rob Hamerling wrote :

>>Now I can reprogram the F88 again
>>even without dongle!!


Jan-Erik Soderholm wrote:

> With internal-MCLR *enabled* ?
> If so, I'm a bit lost...


Yes, please check config word in hex-file: '583F'
I'm a bit lost too.... but I'm happy I didn't loose the F88.

Regards, Rob.

--
Rob Hamerling, Vianen, NL phone +31-347-322822
homepage: http://www.robh.nl/

2005\08\19@185752 by Peter

picon face

On Fri, 19 Aug 2005, Jinx wrote:

> As for the F88 specifically, I've had them in and out of a PIC
> Start Plus and reprogrammed them with ICSP numerous times
> in long sessions and never had your problem. If it's a particular
> one that's doing it, maybe put it aside and use another. If the
> same thing happens again then perhaps you're on to something.
> Not nececelery with the F88 but possibly with your programmer,
> power supply or board
>
> On rare occassions a PIC's gone into a socket backwards, once
> even with 12V on it when I used the wrong PSU, but I've found
> that doesn't always do them in. Often they appear to be fine. My
> experience is that usually they die unexpectedly during development
> for some unknown reason. Could be static, could be a funny glitch
> goes through them. It always seems to be something unrepeatable
> in my case. Fortunately I'm generally kind to my PICs and they
> don't turn up their pins that often

One useful trick is to supply just enough power for the circuit to work.
For exampl if you use a parallel regulator then this is almost always
ensured. If you put something in backwards it will only pass the maximum
shunt current which should not cause damage.

Peter

More... (looser matching)
- Last day of these posts
- In 2005 , 2006 only
- Today
- New search...