Searching \ for 'UV erasable versions' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/index.htm?key=erasable+versions
Search entire site for: 'UV erasable versions'.

Truncated match.
PICList Thread
'UV erasable versions'
1997\02\23@232629 by Joe McCarron

flavicon
face
Hi
Which versions of pic16CXX family are UV erasable?
I've been through the "embedded control handbook" and I can not find
one that is.
Thanks
Joe McCarron

1997\02\24@014134 by Andrew Warren

face
flavicon
face
Joe McCarron <spam_OUTPICLISTTakeThisOuTspamMITVMA.MIT.EDU> wrote:

> Which versions of pic16CXX family are UV erasable? I've been
> through the "embedded control handbook" and I can not find one
> that is.

Joe:

Each of the PICs comes in many packages... You can get them in
plastic DIP, SOIC, SSOP, etc.  One of the options is "Ceramic
Windowed DIP", signified by a "JW" suffix after the part number.

Those "JW" parts are UV-erasable, so long as you don't turn on the
"Code-Protect" bit when you program them.

-Andy

=== Andrew Warren - .....fastfwdKILLspamspam@spam@ix.netcom.com
=== Fast Forward Engineering - Vista, California
===
=== Custodian of the PICLIST Fund -- For more info, see:
=== www.geocities.com/SiliconValley/2499/fund.html

1997\02\24@043631 by Kieran Sullivan

flavicon
face
Setting the Code Protect bit when you program a UV Erasable or even the EEPROM versions of the PIC controllers will not prevent them from being erased. The Code Protect is only there in an attempt to stop you reading back the correct code in the chip.

Kieran


----------
From:   Andrew Warren[SMTP:fastfwdspamKILLspamIX.NETCOM.COM]
Sent:   24 February 1997 06:48
To:     .....PICLISTKILLspamspam.....MITVMA.MIT.EDU
Subject:        Re: UV erasable versions


Those "JW" parts are UV-erasable, so long as you don't turn on the
"Code-Protect" bit when you program them.

-Andy

=== Andrew Warren - EraseMEfastfwdspam_OUTspamTakeThisOuTix.netcom.com
=== Fast Forward Engineering - Vista, California
===
=== Custodian of the PICLIST Fund -- For more info, see:
=== www.geocities.com/SiliconValley/2499/fund.html

1997\02\24@052447 by Andrew Warren

face
flavicon
face
Kieran Sullivan <PICLISTspamspam_OUTMITVMA.MIT.EDU> wrote:

> Setting the Code Protect bit when you program a UV Erasable or even
> the EEPROM versions of the PIC controllers will not prevent them
> from being erased.

Kieran:

For many of the new PICs, enabling the Code Protection WILL prevent
the chips from being erased.  In those newer PICs, the Code-Protect
bits are intended to be NON-ERASABLE in order to improve their
security.

-Andy

=== Andrew Warren - @spam@fastfwdKILLspamspamix.netcom.com
=== Fast Forward Engineering - Vista, California
===
=== Custodian of the PICLIST Fund -- For more info, see:
=== www.geocities.com/SiliconValley/2499/fund.html

1997\02\24@092154 by Andy Kunz

flavicon
face
>Those "JW" parts are UV-erasable, so long as you don't turn on the
>"Code-Protect" bit when you program them.

If you _do_ turn it on, expect about 2 hours of UV to be needed to use your
chip again.

Andy
==================================================================
Andy Kunz - Montana Design - 409 S 6th St - Phillipsburg, NJ 08865
         Hardware & Software for Industry & R/C Hobbies
       "Go fast, turn right, and keep the wet side down!"
==================================================================

1997\02\24@092210 by Andy Kunz

flavicon
face
>For many of the new PICs, enabling the Code Protection WILL prevent
>the chips from being erased.  In those newer PICs, the Code-Protect
>bits are intended to be NON-ERASABLE in order to improve their
>security.

Good intentions don't always pan out.  I've pulled this stupid stunt more
times than I care to admit.

The 12C5xx parts didn't take the full 2 hours, though, like the '7xs did.

Andy
==================================================================
Andy Kunz - Montana Design - 409 S 6th St - Phillipsburg, NJ 08865
         Hardware & Software for Industry & R/C Hobbies
       "Go fast, turn right, and keep the wet side down!"
==================================================================

1997\02\24@092326 by mike

flavicon
picon face
In message  <KILLspam01BC2234.8E0EA720KILLspamspamstargate.bfsec.bt.co.uk> RemoveMEPICLISTTakeThisOuTspamMITVMA.MIT.EDU
writes:
> Setting the Code Protect bit when you program a UV Erasable or even the >
EEPROM versions of the PIC controllers will not prevent them from being >
erased. The Code Protect is only there in an attempt to stop you reading > back
the correct code in the
c
hip.
>
Kieran,

Some of the newer PICs cannot be un-code-protected with UV.

For example, C62x, C73A, 17C44 and many others.

Regards,



Mike Watson

1997\02\24@115441 by Andrew Warren

face
flavicon
face
I wrote:

> For many of the new PICs, enabling the Code Protection WILL prevent
> the chips from being erased.

   I suppose some clarification is in order, since I've received a
   number of incredulous private responses to that statement:

   On the newer PICs, the code-protect bits don't erase because
   they're physically shielded from UV light.  The rest of the
   memory WILL erase, but that doesn't matter since the devices
   can't be reprogrammed while the code-protection is enabled.

   So... If you code-protect one of the newer PICs, you won't be
   able to reprogram it, even though you CAN erase most of it.

   -Andy

=== Andrew Warren - spamBeGonefastfwdspamBeGonespamix.netcom.com
=== Fast Forward Engineering - Vista, California
===
=== Custodian of the PICLIST Fund -- For more info, see:
=== www.geocities.com/SiliconValley/2499/fund.html

1997\02\24@182745 by Andy Kunz

flavicon
face
At 08:57 AM 2/24/97 -0800, you wrote:
>I wrote:
>
>> For many of the new PICs, enabling the Code Protection WILL prevent
>> the chips from being erased.
>
>    I suppose some clarification is in order, since I've received a
>    number of incredulous private responses to that statement:
>
>    On the newer PICs, the code-protect bits don't erase because
>    they're physically shielded from UV light.  The rest of the
>    memory WILL erase, but that doesn't matter since the devices
>    can't be reprogrammed while the code-protection is enabled.
>
>    So... If you code-protect one of the newer PICs, you won't be
>    able to reprogram it, even though you CAN erase most of it.

You CAN erase all of it.  It just takes time.  The metal shield prevents the
light from coming in easily.  It still gets there, and I have the chips to
prove it.  I use them almost daily.

Microchip made several other changes to the newer parts (often the "A" or
3-digit part) in order to foil the hackers, but they can only go so far.
The shield causes light to be attenuated immensely, but it still gets
through enough to reuse the chip after a 2-hour or so suntan.

Please don't mislead folks into thinking that protected windowed parts that
don't seem to erase after the normal time are garbage.  Unless, guys, you
want to send them to me instead.  I'll throw them away for you <G>

Andy
==================================================================
Andy Kunz - Montana Design - 409 S 6th St - Phillipsburg, NJ 08865
         Hardware & Software for Industry & R/C Hobbies
       "Go fast, turn right, and keep the wet side down!"
==================================================================

1997\02\25@041821 by Marc Schmaeche

flavicon
face
>Andrew Warren wrote:
>
>> For many of the new PICs, enabling the Code Protection WILL prevent
>> the chips from being erased.
>
>    I suppose some clarification is in order, since I've received a
>    number of incredulous private responses to that statement:
>
>    On the newer PICs, the code-protect bits don't erase because
>    they're physically shielded from UV light.  The rest of the
>    memory WILL erase, but that doesn't matter since the devices
>    can't be reprogrammed while the code-protection is enabled.
>
>    So... If you code-protect one of the newer PICs, you won't be
>    able to reprogram it, even though you CAN erase most of it.
>
>    -Andy


Dear Andrew,

thank you very much for your statements clearing up the problems with
code-protect bits in UV erasable versions.

But I'm still wondering what sense it makes preventing some bits in windowed
parts with a shield from UV light. If anybody needs the security of code
protection bits he can use the OTP version! Then there is no need for
reprogramming the PIC.

As long as I'm using windowed parts I would expect that they could be erased
in any case. It's a pity that Microchip complicates the usage of the windowed
parts, because I'm always considering windowed parts as an simplification in
the development process (as long as you really could erase them).

Regards,
Marc Schmaeche

ZAM-AZN
Am Weichselgarten 7
91058 Erlangen (Germany)
E-mail: TakeThisOuTmsEraseMEspamspam_OUTzam.nf.fh-nuernberg.de (Ger/Eng/Spa welcome)

1997\02\25@075135 by David Nicholls

flavicon
face
       Wow !
               Would anyone else like to confirm this mail. (That even
new pics can have CP bit erased given enough UV light ). Not that I'm
doubting you Mike just curious if Microchip would like to confirm that
this is a design feature rather than a fault in Mike's chips...

                               Thanks..
                                               David.




On Mon, 24 Feb 1997, Andy Kunz wrote:

{Quote hidden}

1997\02\25@075551 by tjaart

flavicon
face
David Nicholls wrote:
>
>         Wow !
>                 Would anyone else like to confirm this mail. (That even
> new pics can have CP bit erased given enough UV light ). Not that I'm
> doubting you Mike just curious if Microchip would like to confirm that
> this is a design feature rather than a fault in Mike's chips...
>
>                                 Thanks..
>                                                 David.
>

Shhhtttt! Just now they 'fix' it ;-)

--
Friendly Regards

Tjaart van der Walt
RemoveMEtjaartspamTakeThisOuTwasp.co.za
_____________________________________________________________
| Another sun-deprived R&D Engineer slaving away in a dungeon |
|             ASP International  http://wasp.co.za            |
|             GSM and GPS value-added applications            |
|  Voice : +27-(0)11-622-8686   |   Fax : +27-(0)11-622-8686  |
|_____________________________________________________________|

1997\02\25@083946 by Stuart Tyrrell

flavicon
picon face
David Nicholls wrote:
>
>         Wow !
>                 Would anyone else like to confirm this mail. (That even
> new pics can have CP bit erased given enough UV light ). Not that I'm
> doubting you Mike just curious if Microchip would like to confirm that
> this is a design feature rather than a fault in Mike's chips...

Not that I've played with a lot of windowed chips but......

Wouldn't the design of the devices be such that the CP bit
was under another metallisation layer? This would make it fairly
(but possibly not completely) opaque to UV. I certainly wouldn't
be suprised if it could be erased given enough UV.

Of course the CP bit could be implemented as a true fuse.

What's the security problem with just ensuring that the CP bit takes
*much* longer than the code to erase anyway? It's not as if anybody
with the resources to defeat the CP bit (eg by selectively exposing
it) wouldn't be likely to have the resources to defeat it no matter
how it was implemented........




Stuart.

1997\02\25@095657 by Andy Kunz

flavicon
face
At 01:10 PM 2/25/97 +0000, you wrote:
>David Nicholls wrote:
>>
>>         Wow !
>>                 Would anyone else like to confirm this mail. (That even
>> new pics can have CP bit erased given enough UV light ). Not that I'm
>> doubting you Mike just curious if Microchip would like to confirm that
>> this is a design feature rather than a fault in Mike's chips...

I was told to do this by my contact inside Microchip.

>Of course the CP bit could be implemented as a true fuse.

PLEASE DON'T GIVE THEM ANY IDEAS !

>What's the security problem with just ensuring that the CP bit takes
>*much* longer than the code to erase anyway? It's not as if anybody
>with the resources to defeat the CP bit (eg by selectively exposing
>it) wouldn't be likely to have the resources to defeat it no matter
>how it was implemented........

A very good point indeed.  As the difficulty goes up, so does the cost.  At
some point it costs you more to clone than to code it yourself.  I think
that's the real target.

I don't know why they don't just move over to FLASH like Atmel has done.

Andy
==================================================================
Andy Kunz - Montana Design - 409 S 6th St - Phillipsburg, NJ 08865
         Hardware & Software for Industry & R/C Hobbies
       "Go fast, turn right, and keep the wet side down!"
==================================================================

1997\02\25@124535 by Eric Smith

flavicon
face
Stuart Tyrrell <stuartEraseMEspam.....STDEVEL.DEMON.CO.UK> wrote:
> Wouldn't the design of the devices be such that the CP bit
> was under another metallisation layer?

Yes, that's exactly what they've done.

> Of course the CP bit could be implemented as a true fuse.

Not likely.  They would have to use additional process steps to make
Ti-W or nichrome fuses, which is expensive, tricky, and (in managementspeak)
far from their core competency.

> What's the security problem with just ensuring that the CP bit takes
> *much* longer than the code to erase anyway? It's not as if anybody
> with the resources to defeat the CP bit (eg by selectively exposing
> it) wouldn't be likely to have the resources to defeat it no matter
> how it was implemented........

No, it's relatively easy to deencapsulate an OTP and selectively expose
it to UV.  It's a lot more work to microprobe it.  So the metalization over
the code protect bit provides a small increase in security at no cost.
Too bad they didn't also implement the code-protect-disable bit to keep
the windowed parts from becoming jewelry.

Cheers,
Eric

1997\02\25@232708 by tjaart

flavicon
face
> A very good point indeed.  As the difficulty goes up, so does the cost.  At
> some point it costs you more to clone than to code it yourself.  I think
> that's the real target.
>
> I don't know why they don't just move over to FLASH like Atmel has done.
>
> Andy
> ==================================================================
> Andy Kunz - Montana Design - 409 S 6th St - Phillipsburg, NJ 08865
>           Hardware & Software for Industry & R/C Hobbies
>         "Go fast, turn right, and keep the wet side down!"
> ==================================================================

I understand that the technology is slower. This is the reason the
84's are 10MHz max. The reason you won't see EEPROM on the other PICs
is because the EEPROM memory can only be produced on chips that
use the same technology to store the program memory.
--
Friendly Regards

Tjaart van der Walt
EraseMEtjaartspamwasp.co.za
_____________________________________________________________
| Another sun-deprived R&D Engineer slaving away in a dungeon |
|             ASP International  http://wasp.co.za            |
|             GSM and GPS value-added applications            |
|  Voice : +27-(0)11-622-8686   |   Fax : +27-(0)11-622-8686  |
|_____________________________________________________________|

1997\02\26@194638 by Eric Smith

flavicon
face
Andy Kunz <RemoveMEmontanaEraseMEspamEraseMEFAST.NET> wrote regarding Microchip:
> I don't know why they don't just move over to FLASH like Atmel has done.

But is Atmel really using Flash technology, or are they just calling their
old EEPROM technology "Flash" like Microchip is doing with the 16F83 and
16F84?  This is what's known as a "Marketing Breakthrough".

jaart van der Walt <RemoveMEtjaartspam_OUTspamKILLspamWASP.CO.ZA> wrote:
> I understand that the technology is slower.

As far as reading goes, EPROMs, EEPROMs, and Flash cells all have similar
timing when implemented in comparable processes.

> This is the reason the 84's are 10MHz max.
Apparently the high-endurance EEPROM process used for the data EEPROM in the
16C84, 16F83, and 16F84 is a lot different than the EPROM process used in
other parts.  But it is not clear to me why the program EEPROM in those parts
is so slow; it is not designed for high endurance.  Maybe in order to get
high endurance for the data EEPROM they have to make the part using some old
process with really huge geometry.  By my measurements, the 16C84 is only
capable of running at 0.4x the speed of the first-generation OTP PICs
(i.e., 16C71, claimed to be 1.5 micron), and about 0.2x the speed of the
newer PICs (i.e., 16C64, claimed to be 0.9 micron).

> The reason you won't see EEPROM on the other PICs
> is because the EEPROM memory can only be produced on chips that
> use the same technology to store the program memory.

I'm not aware of any major technical impediment to that; other vendors have
implemented true Flash memory and high-endurance byte-erasable EEPROM on the
same die.

Cheers,
Eric

1997\02\26@233919 by tjaart

flavicon
face
Eric Smith wrote:
>

> > The reason you won't see EEPROM on the other PICs
> > is because the EEPROM memory can only be produced on chips that
> > use the same technology to store the program memory.
>
> I'm not aware of any major technical impediment to that; other vendors have
> implemented true Flash memory and high-endurance byte-erasable EEPROM on the
> same die.

Sorry, I meant 'cheaply', and normal PROM technology mixed with
Flash/EEPROM
technology

--
Friendly Regards

Tjaart van der Walt
RemoveMEtjaartTakeThisOuTspamspamwasp.co.za
_____________________________________________________________
| Another sun-deprived R&D Engineer slaving away in a dungeon |
|             ASP International  http://wasp.co.za            |
|             GSM and GPS value-added applications            |
|  Voice : +27-(0)11-622-8686   |   Fax : +27-(0)11-622-8686  |
|_____________________________________________________________|

1997\02\27@064756 by Andy Kunz

flavicon
face
At 12:04 AM 2/27/97 -0000, you wrote:
>Andy Kunz <EraseMEmontanaspamspamspamBeGoneFAST.NET> wrote regarding Microchip:
>> I don't know why they don't just move over to FLASH like Atmel has done.
>
>But is Atmel really using Flash technology, or are they just calling their
>old EEPROM technology "Flash" like Microchip is doing with the 16F83 and
>16F84?  This is what's known as a "Marketing Breakthrough".

You issue a page erase command to blank it.  You tell me.

Andy
==================================================================
Andy Kunz - Montana Design - 409 S 6th St - Phillipsburg, NJ 08865
         Hardware & Software for Industry & R/C Hobbies
       "Go fast, turn right, and keep the wet side down!"
==================================================================

1997\02\27@072813 by tjaart

flavicon
face
Andy Kunz wrote:
>
> At 12:04 AM 2/27/97 -0000, you wrote:
> >Andy Kunz <RemoveMEmontanaKILLspamspamFAST.NET> wrote regarding Microchip:
> >> I don't know why they don't just move over to FLASH like Atmel has done.
> >
> >But is Atmel really using Flash technology, or are they just calling their
> >old EEPROM technology "Flash" like Microchip is doing with the 16F83 and
> >16F84?  This is what's known as a "Marketing Breakthrough".
>
> You issue a page erase command to blank it.  You tell me.
>

On the PIC JW parts, you issue a 'write protect' bit to render it
useless.
<VVBG>

--
Friendly Regards

Tjaart van der Walt
tjaartSTOPspamspamspam_OUTwasp.co.za
_____________________________________________________________
| Another sun-deprived R&D Engineer slaving away in a dungeon |
|             ASP International  http://wasp.co.za            |
|             GSM and GPS value-added applications            |
|  Voice : +27-(0)11-622-8686   |   Fax : +27-(0)11-622-8686  |
|_____________________________________________________________|

1997\02\27@151942 by Eric Smith

flavicon
face
Tjaart van der Walt <spamBeGonetjaartSTOPspamspamEraseMEWASP.CO.ZA> wrote:
> Sorry, I meant 'cheaply', and normal PROM technology mixed with
> Flash/EEPROM technology

I assume that you really mean EPROM technology.  AFAIK, PROM technology has
never been used in microcontrollers.  I've never even heard of MOS PROMs,
only bipolar.

EPROM and EEPROM can definitely be used together.  There have been a fair
number of microcontrollers with this combination.

EPROM and Flash could be used together, but there would be very little point
to it.  Flash cells are only slightly larger than EPROM cells, and are about
the same speed.

Cheers,
Eric

1997\02\28@103542 by myke predko

flavicon
face
>At 12:04 AM 2/27/97 -0000, you wrote:
>>Andy Kunz <KILLspammontanaspamBeGonespamFAST.NET> wrote regarding Microchip:
>>> I don't know why they don't just move over to FLASH like Atmel has done.
>>
>>But is Atmel really using Flash technology, or are they just calling their
>>old EEPROM technology "Flash" like Microchip is doing with the 16F83 and
>>16F84?  This is what's known as a "Marketing Breakthrough".
>
>You issue a page erase command to blank it.  You tell me.

Andy.  If you look through the EEPROM Spec, you'll see that you can use the
"Disabling Code-Protection" procedure to erase the all the EEPROM all at
once.  In my programmer, I use this command to erase all the EEPROM (even if
the CP bit isn't set) before programming.

Would this fit your definition as a "Flash Page Erase"?

Sorry, I'm not trying to be annoying or difficult (and probably failing),
but "Flash" is a really loose definition because of situations like above.
I agree that the "correct" definition is to have EEPROM cells arranged in
such a way that a group of them (ie a "page") can be erased; but this has
been blurred over time.

Actually, I like the use by Microchip of putting the "F" in the part number
to identify the EEPROM/Flash parts.  Now, if they'd only come up with a
16F73A...

myke

"I don't do anything that anybody else in good physical condition and
unlimited funds couldn't do" - Bruce Wayne

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