I should mention two other items.  First, it occurs to me that flash CAN lose
its charge after time.  Generally a LONG time, but I recall that programming a
flash memory means hitting each bit several times.  This may account for the
long programming times in the f chips.  (coincidentily, I'm specing a mitsibishi
chip with 256K of flash on board which takes less than 8 seconds to program.
Wonder why Microchip's flash takes so long...?)

It makes me wonder how robust internal programming is when compared with
external programming, and the need for checksums in code expected to last a long
time.

Secondly, I left out one reason where a user may want to enable internal writing
without internal reading.

This would be useful if one was afraid that someone would crack their internal
writing protocol/encryption/etc, as in the case of our anonymous poster.

HOWEVER, this is completely useless.  If they can defeat your protocol and
reprogram the chip, they can simply read the data stream you are writing during
an upgrade.  If you want to prevent this, you have to be physically present at
the device, which, of course, our anonymous poster is strongly against.

So, again, the most complete, but redundant in 99.99% of all cases, code
protection would involve 4 bits, namely: internal read, internal write, external
read and external write.  2 bit code protection (internal protect, external
protect) would handle all but the most strange and obtuse requirements for code
protection.

The four code protection bits proposed by our anonymous poster are, IMHO,
redundant and not very clear.  It would be best to simplify them in one of the
two ways above.

-Adam

"M. Adam Davis" wrote:
>
> The only thing I don't like about this is I am NOT going to trust a programmed
> PIC until I've verified it.  You don't seem to provide any method of programming
> the chip while protected and verifying the program.
>
> > DISABLE INTERNAL READS OF FLASH MEMORY
> > DISABLE ICSP
> > ACTIVATE CODE PROTECTION FOR FLASH ROM, perhaps bank by bank of you like
> > ALLOW OVERWRITING CODE PROTECTED FLASH (but never can read it!)
>
> Could be simplified as two bits for each bank:
>
> Do not allow external program access (read or write)
> Do not allow internal program access (read or write)
>
> I don't see a need to provide a seperate bit which allows internal writing but
> not internal reading.  You are the one putting the code in, right?  If you don't
> want your program to read the code, don't put any code reading instructions in
> your program.  The ONLY instance I can see where this would be valuable is if
> you allow external writing to the chip, but not external reading.  In that case,
> you could change some of the program, but you couldn't put in code which would
> read out the contents of the chip.  Since you did not give the option of writing
> externally, but not reading, I assume that this is then a moot situation, and
> therefore you may as well enable and disable internal reading and writing
> together.
>
> Likewise, "DISBALE ICSP" and "ACTIVATE CODE PROTECTION FOR FLASH ROM" appear to
> be redundant.  In fact, I am unsure what you mean by the activate statement, are
> you trying to make a bit that enables the other code protection bits, or is it
> to implement a complete code protection no matter what the other bits are set
> to?
>
> You can essentially boil this entire system down to a four by four matrix.  You
> have two methods of accessing the program memory (internal and external) and two
> operations you can perform in either method (read or write)
>
>       Internal   External
> READ
> WRITE
>
> Now, we know that having seperate bits for external read and write is nearly
> redundant.  If you enable read but not write, they can rip the program, change
> it and reflash the entire chip.  If you enable write without read they can
> insert code which will read out the memory (depending on the settings of the
> internal bits).
>
> The only time read and write enable from and internal source would not be
> redundant is spelled out above.
>
> So, in a nutshell, if you want to enable external writing without reading, you
> will have to have EXACTLY 4 code protection bits, because there will be those
> who will complain if you only give them three.  (and we have to please everyone,
> right?)
>
> If you see no reason to use such a feature (handling program changes internally
> should give designers more than enough latitude), then you only need EXACTLY 2
> code protection bits.
>
> I suspect that there will be those who will want to have 2 bits per bank, so a
> four bank device will need one byte just for code protection.
>
> -Adam
>
> anonlistpost anonlistpost wrote:
> >
> > Can anyone who sees liabilities in the following code protect design post
> > about any holes they can see?
> >
> > DISABLE INTERNAL READS OF FLASH MEMORY
> > DISABLE ICSP
> > ACTIVATE CODE PROTECTION FOR FLASH ROM, perhaps bank by bank of you like
> > ALLOW OVERWRITING CODE PROTECTED FLASH (but never can read it!)
> >
> > Thanks.
> >
> > Bill Davis

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