Searching \ for '[PIC]: about the flash memory on the 16F877' 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/memory.htm?key=memory
Search entire site for: 'about the flash memory on the 16F877'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: about the flash memory on the 16F877'
2001\07\17@234712 by Ron Anthony

flavicon
face
Hello All.  I am currently struggling with how to deal with the ridiculously
bad code protect on the 16F877.  I am hoping to learn a few things from
those who are actively working with the flash memory.

Here is the primary question:

If I code protect the upper half of the chip, that is, 50% of the flash
memory, will someone be able to use an ICSP to put in code on the open lower
half that can internally read the code protected space and dump the contents
out of a port?  Because if they can, there is no sense code protecting that
half of the chip.  If I code protect the 256 bytes, can they not read those
as well?  From what I understand, internal flash reads work on code
protected memory.  So it is very easy to set up a memory dump of the code
protected space.  Is this correct?

If that is the case, my only options are to code protect the entire chip
(which will prevent memory dumps, but turns the flash part into an OTP part)
or to leave the chip totally naked for downloading and reverse engineering
and copying, however, I'll be able to distribute flash updates.  We can not
use ICSP in the field, as this would require distributing the rom image in
its naked entirety, which is not an option.  Plus there are no facilities on
the PCB for enabling ICSP as we used all the pins and the circuit design is
done.

My last option is to code protect the entire chip, and have no option for
flash updates in the field by bootloader, and then, when the 77A comes out
(never???) we can simply eat the cost and send out new 77A chips to
everyone, and let them throw away their code protected 77s, which would
basically be useless.  There is a socket on the PCB but the tool to remove
the part (a spring loaded PLCC removal tool) costs as much as the chip.  So
even a chip recall would not be worth the trouble, that is, to have everyone
mail back there 77 chips, then bulk erase, then resell as one-offs.  It
would not be worth the trouble.  And if you pop out the chip with a paper
clip, for example, you'd bend the pins quite a bit unless you get real
lucky.

In the meantime, I am buying my 16F877 at 20 MHz in the PLCC package for a
very good price and soon will have thousands in stock.  If someone needs
some 16F77-20/L with no lead time and a very good price, let me know. I can
sell you some of my stock, we've got a big pipeline streamed and coming in.

At any rate, what are your thoughts on the flash memory and how to deal with
it?

Thanks all, from Ron Anthony

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\07\18@013915 by Tony Nixon

flavicon
picon face
Ron Anthony wrote:
>
> Hello All.  I am currently struggling with how to deal with the ridiculously
> bad code protect on the 16F877.  I am hoping to learn a few things from
> those who are actively working with the flash memory.
>
> Here is the primary question:
>
> If I code protect the upper half of the chip, that is, 50% of the flash
> memory, will someone be able to use an ICSP to put in code on the open lower
> half that can internally read the code protected space and dump the contents
> out of a port?  Because if they can, there is no sense code protecting that
> half of the chip.  If I code protect the 256 bytes, can they not read those
> as well?  From what I understand, internal flash reads work on code
> protected memory.  So it is very easy to set up a memory dump of the code
> protected space.  Is this correct?

You can't read or write code protected ROM from within the chip, or from
a programmer or from ICSP.

Ages ago there was some threads about having a special config bit that
would allow the chip to rewrite itself underneath the code protection.
ie. the ROM can't be accessed from outside the chip but it can be
rewritten internally. That way a bootloader could use encrypted code to
update itself.

Not a reality though and I guess, unless you are confident that the
protected code will not need replacing, then using a bootloader for
upgrades is no option.

--
Best regards

Tony

mICros
http://www.bubblesoftonline.com
spam_OUTsalesTakeThisOuTspambubblesoftonline.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\07\18@014600 by Ron Anthony

flavicon
face
Tony, the FAE for microchip told me that internal flash reads can occur
perfectly well on code protected memory, that the point of the code
protected memory was not to defeat hackers or code copyers, but rather to
protect you from overwriting your own code.  Are you sure that the code
protected flash can't be read with internal flash reading code???

{Original Message removed}

2001\07\18@021005 by M. Adam Davis

flavicon
face
Firstly, this has been hashed and rehashed on this list multiple times.
Please check the archives.  All your questions, and more, are answered
there.

As per page 46 of  the 16F87x data sheet (DS30292C):
You CANNOT write (Internally via program instructions, or externally via
ICSP) to program memory that has been code protected, and you cannot
write internally via program instructions to any program memory if the
WRT bit is cleared in the config.  The WRT bit does not affect ICSP
reads or writes.  The ICSP cannot read or write protected areas.

NOTHING affects the ability of the chip to read its own memory.  If you
leave ANY part of the chip unprotected, code can be written to that
space which will read out ALL the code on the chip if the chip executes
instructions in that area.

Code protection cannot be removed without a block erase of the entire chip.

What this all boils down to is that you based your design on a product
(77A) which was not available at the time you locked it into the
project, and you are officially out of luck.  This is NOT Microchip's
'fault', nor could one say that their code protect is 'bad'.  If you've
been in the industry for a long time you'll have realized that you do
not lock your design into a part you do not have in hand.

IIRC, there really was no good solution.  As you indicated, for complete
protection the chip is essentially an OTP part.  There is no way to
leave a part of the chip unprotected without the possibility of someone
inserting code to read the unprotected part out, unless you can insure
that code inside the unprotected area is never run, only read (as in
data), but that defeates the purpose of updating or upgrading the program.

If you hadn't already designed the hardware, I'd suggest you add a
12cxxx part to the project which contains critical pieces of code (ie,
your most secret routines shouldn't need upgrading, should they?) and
have it code protected.  Using a simple encryption/decryption between
the two chips you can leave the main chip open for upgrades and
non-proprietary processing, while the 12Cxxx acts as a dongle, doing the
important bits of work.  Hopefully your product has a specific function
which does not change over time.  If it does, perhaps the fault lies not
in the part, but in the design.

But then, why do you really need the upgradeability?  Assuming you
aren't turning into a bad software engineer and are releasing shoddy
work with planned upgrades to full functionality, I can think of few
reasons to use upgradeable capabilities, and many of those can be
overcome by good planning and design.  As we move into parts with more
than 8k of program space, this may be more of a concern as debugging
larger programs becomes more difficult.  By then, though, we'll have
chips with much better code protection abilities.

-Adam

P.S.  I'm sorry if I appear to be rude in any way.  Sending 3 high
priority messages to the list ranting about how badly a particular
product is designed, placing blame/fault on a company that has done
nothing wrong, coupled with it being too late for me to approach nearly
anything rationally... well, it irritated me tonight.  I do hope,
however, that this information was useful  (which it should be unless
you were asking rhetorical questions ;-)

It does, however, stimulate my mind into another thought...  Hmmm...

Ron Anthony wrote:

{Quote hidden}

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\07\18@022607 by Ron Anthony

flavicon
face
Hello Adam.  Thanks for taking the time to write.  We did design for the 77,
we knew of its very poor (non-existent?) code protection of FLASH memory,
but chose the part anyway, took a gamble that the 77A would be available by
go time, but it's not.  We never knew that even code protected flash was
readable by internal reads, meaning that any amateur hacker could put on
code to do a memory dump of the code protected area.  That is the achilles
heel we didn't know about.  That seems quite ridiculous, and in fact, is.

The 77A was due out long ago, and is quite far delayed into the future, so
now we are stuck with a poorly designed part.  To say it's not microchip's
fault is quite remarkable, given that the ONLY part of the chip that's not a
commodity is the ROM image, and they've seen to it that it's impossible to
protect. Again, TOTALLY RIDICULOUS.

Do you have any suggestions how to preserve the flashability of the part
through our bootloader while still protecting the chip from code copying and
downloading, etc?

Thank for any insight you can provide, it is truly appreciated, from a coder
in a jam!!!

-----Original Message-----
From: pic microcontroller discussion list
[.....PICLISTKILLspamspam@spam@MITVMA.MIT.EDU]On Behalf Of M. Adam Davis
Sent: Wednesday, July 18, 2001 1:50 AM
To: PICLISTspamKILLspamMITVMA.MIT.EDU
Subject: Re: [PIC]: about the flash memory on the 16F877

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\07\18@024034 by M. Adam Davis

flavicon
face
Ron Anthony wrote:

>Do you have any suggestions how to preserve the flashability of the part
>through our bootloader while still protecting the chip from code copying and
>downloading, etc?
>
Nope.  I'd say you are in quite a pickle.
You have a few options:
1) Give up on the idea of upgrading the part in the field/by the customer
2) Give up on the idea of having complete code protection
3) Redesign your project to work with a part that, in your estimation,
is not 'broken'
4) Seperate the project into
  a) Important, copy protected and non-upgradable bits
  b) Less Important, non-protected, upgradeable bits
  and redesign the project to use two chips, one protected and one not
5) Be up front with the customer and tell them you gambled and lost, and
that they'll have to distribute upgrade chips and tools until the better
chip comes out
6) Give us more of an idea as to what your project/product is/does (in a
broad sense) so we may be able to suggest a better workaround, or at
least tell us why you must have both copy protection and field upgrade
capability, so we can suggest a possible work around.

>Thank for any insight you can provide, it is truly appreciated, from a coder
>in a jam!!!
>
Glad to be of assistance - good luck!  Sound like you've hit the
immutable law of three - choose two: Upgradeable, Cheap, Protected.
Hopefully a compromise or kluge can be found.

-Adam

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\07\18@044624 by Bob Ammerman

picon face
Note that the "B" version of the 877 datasheet, which is likely what Ron
designed form, does _not_ explain the 'errata' if you will re: code protect.
I think this gives him a certain justification for his own actions and for
his irritation with mChip.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

----- Original Message -----
From: "Ron Anthony" <.....ronantKILLspamspam.....OPTONLINE.NET>
To: <EraseMEPICLISTspam_OUTspamTakeThisOuTMITVMA.MIT.EDU>
Sent: Wednesday, July 18, 2001 12:29 AM
Subject: Re: [PIC]: about the flash memory on the 16F877


> Hello Adam.  Thanks for taking the time to write.  We did design for the
77,
> we knew of its very poor (non-existent?) code protection of FLASH memory,
> but chose the part anyway, took a gamble that the 77A would be available
by
{Quote hidden}

and
> downloading, etc?
>
> Thank for any insight you can provide, it is truly appreciated, from a
coder
> in a jam!!!
>
> {Original Message removed}

2001\07\18@064148 by Neil Gandler

flavicon
face
Ok, I have the same exact concerns as Ron, but I plan to use the new
PIC18Fxxx devices. I plan to call Microchip this week and find out if the
18F series chips will suffer from the same problems discussed in this
thread.  I think Ron has some very relevant points. I don't think it is
asking too much to have the following properties in these new Flash PICS

1. Allow the engineer to disable the ability to read and write to/from
program memory via the ICSP/ICD interface pins AND allow the engineer to
disable in-circuit debugging via the ICSP/ICD interface. If the engineer
wants to reprogram the chip via ICSP/ICD interface or use an ICD with the
PIC, it should require a full erase first. An erase cycle that leaves no
trace of the previous firmware build.
2. With ICSP/ICD interface reads and writes disabled (as mentioned in #1),
your firmware should still have the ability to perform reads and writes to
the internal program memory. This will still allow for firmware updates via
an internal bootloader routine (excluding the memory locations of the
bootloader).

I don't think Ron is asking too much of Microchip. The above properties give
us the best of all words:

Protection from reverse engineering of code, but allowing internal firmware
updates via a software bootloader, perhaps custom designed with some type of
internal decryption algorythm for maxmium protection for publically
available firmware upgrades. Kind of like a bootloader firewall for your
PIC.

Now the important question, will the A version of the PIC16F77 have the
above properties? And more importantly for me and perhaps others, will the
18F series devices have these above properties.
When I get an answer from Microchip, I will post what I am told. Thanks

Neil Gandler
Founder, CTO
MAI Technology Inc.
P.O. Box 64072
Sunnyvale, CA 94088-4072
Phone & Fax: 408-904-5089
e-mail: neil_gandlerspamspam_OUTgetmai.com
http://www.getmai.com
{Original Message removed}

2001\07\18@104328 by David Dunn

flavicon
face
>Hello Adam.  Thanks for taking the time to write.  We did design for the 77,
>we knew of its very poor (non-existent?) code protection of FLASH memory,
>but chose the part anyway, took a gamble that the 77A would be available by
>go time, but it's not.  We never knew that even code protected flash was
>readable by internal reads, meaning that any amateur hacker could put on
>code to do a memory dump of the code protected area.  That is the achilles
>heel we didn't know about.  That seems quite ridiculous, and in fact, is.


this isn't quite correct.

you can't put any code on the part to do a memory dump on a protected chip.  if all the program memory is marked as
protected, you can't write to it (at least externally) so you can't get any code on there to do a read then dump.

i've just tested this to be sure on my f877's, if i set code protect on, i can't write back to them at all until i do
an erase operation on the part.


david dunn

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\07\18@104950 by David Dunn

flavicon
face
Adam,

I have to say I agree with you .. seems pretty silly to design on the hope that a future product is going to be
available and work exactly like it should (on time , under budget, blah blah blah)

I design using parts i know i can get overnight UPS red that *everybody* keeps in stock.  I'm using an 877 on my
product too but i just built an ICSP port on the board so the end user can just mail it back to me for upgrades. easy
/ cheap / works.

david dunn

>
>P.S.  I'm sorry if I appear to be rude in any way.  Sending 3 high
>priority messages to the list ranting about how badly a particular
>product is designed, placing blame/fault on a company that has done
>nothing wrong, coupled with it being too late for me to approach nearly
>anything rationally... well, it irritated me tonight.  I do hope,
>however, that this information was useful  (which it should be unless
>you were asking rhetorical questions ;-)
>

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


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