Post by thread:UV erasable versions

Joe McCarron <spam_OUTPICLISTTakeThisOuTMITVMA.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 - .....fastfwdKILLspam@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

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:fastfwdKILLspamIX.NETCOM.COM] Sent: 24 February 1997 06:48 To: .....PICLISTKILLspam.....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_OUTTakeThisOuTix.netcom.com === Fast Forward Engineering - Vista, California === === Custodian of the PICLIST Fund -- For more info, see: === www.geocities.com/SiliconValley/2499/fund.html

Kieran Sullivan <PICLISTspam_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@fastfwdKILLspamix.netcom.com === Fast Forward Engineering - Vista, California === === Custodian of the PICLIST Fund -- For more info, see: === www.geocities.com/SiliconValley/2499/fund.html

>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!" ==================================================================

>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!" ==================================================================

In message <KILLspam01BC2234.8E0EA720KILLspamstargate.bfsec.bt.co.uk> RemoveMEPICLISTTakeThisOuTMITVMA.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

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 - spamBeGonefastfwdspamBeGoneix.netcom.com === Fast Forward Engineering - Vista, California === === Custodian of the PICLIST Fund -- For more info, see: === www.geocities.com/SiliconValley/2499/fund.html

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!" ==================================================================

>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: TakeThisOuTmsEraseMEspam_OUTzam.nf.fh-nuernberg.de (Ger/Eng/Spa welcome)

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}> 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!" > ================================================================== >

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 RemoveMEtjaartTakeThisOuTwasp.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 | |_____________________________________________________________|

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.

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!" ==================================================================

Stuart Tyrrell <stuartEraseME.....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

> 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 EraseMEtjaartwasp.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 | |_____________________________________________________________|

Andy Kunz <RemoveMEmontanaEraseMEEraseMEFAST.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_OUTKILLspamWASP.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

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 RemoveMEtjaartTakeThisOuTspamwasp.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 | |_____________________________________________________________|

At 12:04 AM 2/27/97 -0000, you wrote: >Andy Kunz <EraseMEmontanaspamspamBeGoneFAST.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!" ==================================================================

Andy Kunz wrote: > > At 12:04 AM 2/27/97 -0000, you wrote: > >Andy Kunz <RemoveMEmontanaKILLspamFAST.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 tjaartSTOPspamspam_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 | |_____________________________________________________________|

Tjaart van der Walt <spamBeGonetjaartSTOPspamEraseMEWASP.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

>At 12:04 AM 2/27/97 -0000, you wrote: >>Andy Kunz <KILLspammontanaspamBeGoneFAST.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