Searching \ for '[PIC]: Who else uses 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/devices.htm?key=16F
Search entire site for: 'Who else uses the 16F877?'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Who else uses the 16F877?'
2001\07\17@153134 by Ron Anthony

flavicon
face
Hello all, who else uses the 16F877?  Who else is totally disgusted that the
77A revision is delayed until next March at the earliest???  The 77 is a
flash chip that if you leave it flash upgradable, you must leave it
completely NAKED for copying.  Is this as ridiculous as I think it is?  If
you code protect the flash it becomes OTP memory that can never be updated
without wiping out the entire chip, which means your bootloader code is GONE
and can't be used to update the flash.

Your options are:

1.      leave the chip 100% naked and copyable, downloadable, and 100%
reverse
engineer-able

2.      code protect 50% of the ram, making that half OTP style memory, you
can't
use a bootloader on it, and the other half is still naked

3.      protect only 256 bytes, which prevents whole chip copying, but all
that
is missing is 256 bytes from someone's downloaded code, leaving them only
256 bytes to recreate.

None of these options are good.  The 77A revision is much more secure.  You
can, supposedly, disable in circuit serial programming, and can also disable
interal flash reads.  The chip is secure, the only liability being someone
watching your comms when you update by way of the bootloader.  But, this can
be solved with encryption algorithms that decode the flash update after
getting blocks of data into the chip where it can't be watched.

Microchip had the last 2 years to get out the 77A revision.  What the heck
is keeping this multi-billion dollar company from getting this chip out?  Do
they have no respect whatsoever for the very code that runs in their chip?
Most times that's the only non-commodity part of a device!!!!!

Who else is utterly disappointed about this?  Now I have the tortured
decision to make on a very large production run.  Should I leave the chip
naked and throw caution to the wind?  Should I code protect half the chip
with what code can be reasonably considered "stable" ???  Or should I leave
the whole chip naked but for the 256 bytes they allow?  Not hard to get
around that, having everything but 256 bytes.

Any thoughts?  Advise?  Words of wisdom????

Thanks All.
Ron Anthony, a very disappointed buyer

--
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@050128 by Wollenberg, Frank

flavicon
face
Ron Anthony [spam_OUTronantTakeThisOuTspamOPTONLINE.NET] wrote:

> Hello all, who else uses the 16F877?  Who else is totally
> disgusted that the
> 77A revision is delayed until next March at the earliest???
> The 77 is a
> flash chip that if you leave it flash upgradable, you must leave it
> completely NAKED for copying.  Is this as ridiculous as I
> think it is?  If
> you code protect the flash it becomes OTP memory that can
> never be updated
> without wiping out the entire chip, which means your
> bootloader code is GONE
> and can't be used to update the flash.

I've written a new app. Running in embedded environment and many identical
devices on one bus,
i wanted to include a bootloader. Same questions for me.
Using the bootloader approach, i must leave the chip unprotected (upper 256
words protected).
Happy reverse-engineering !!!!
I have read the data manual for the 16F77, hoping this chip handles the
protection better. But: no opinion for system upgrade, the program memory is
only readible for program verification. This gives a little bit more
security, but no more support in the field. So the only solution was and is
to use the 'F87X.
I'm very disappointed.

> The 77A revision is much more secure.  You
> can, supposedly, disable in circuit serial programming, and
> can also disable interal flash reads.

I have not read the data manual. What is the background for disabling
internal flash read. It makes no sense for me.

> The chip is secure, the only liability being someone
> watching your comms when you update by way of the bootloader.

Does this mean, that the chip can update his program memory while it is
protected against reading via ICSP ? If so, then there are no more problems.
I must read the manual...

Frank

-----------------------------------

GSP Sprachtechnologie GmbH
Frank Wollenberg
HW-Entwicklung
Tel.:   +49 (0)30 769929-78
Fax:    +49 (0)30 769929-12
eMail:  .....f.wollenbergKILLspamspam@spam@gsp-berlin.de


--
GSP Sprachtechnologie GmbH
Teltowkanalstr.1, D-12247 Berlin
Tel.:  +49 (0)30 769929-0
Fax:   +49 (0)30 769929-12
eMail: InfospamKILLspamgsp-berlin.de
Web:   http://www.gsp-berlin.de

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