Do I assume correctly that Flash memory on a 16F877 can't
be enabled for internal writes and disabled for external reads
at the same time ? (Table 4-1 of F877 manual). Is it just that
simple or is there a workaround ?
On Sun, Jul 14, 2002 at 06:33:42PM +1200, Jinx wrote:
> Do I assume correctly that Flash memory on a 16F877 can't
> be enabled for internal writes and disabled for external reads
> at the same time ? (Table 4-1 of F877 manual). Is it just that
> simple or is there a workaround ?
It is just that simple. An unfortunate side effect that one extra bit in the
config register could have resolved.
BTW from my recent reading of of the 18F series chips, the config register
is readable and writable programmatically. So it should be possible to to
only disable code protection under program control. So for example one could
send an encrypted stream with an authorization code. The internal program can
temporarily disable code protection, write the new code, then reenable it.
> > Do I assume correctly that Flash memory on a 16F877 can't
> > be enabled for internal writes and disabled for external reads
> > at the same time ? (Table 4-1 of F877 manual). Is it just that
> > simple or is there a workaround ?
>
> It is just that simple. An unfortunate side effect that one extra bit
> in the config register could have resolved.
Oh, fudge
I'm debating whether to remove RB6 and/or RB7 in that case to
thwart "enthusiastic amateurs", once the code has been finalised
>Oh, fudge
>
>I'm debating whether to remove RB6 and/or RB7 in that case to
>thwart "enthusiastic amateurs", once the code has been finalised
>
>
But, but... Information *wants* to be free! Your program _yearns_ to
be extended!
;-)
All kidding aside, any chip missing pins is just screaming to be hacked.
Might make the enthusiastic even more so.
But then, if the code is finalised then you don't need to update the
chip, right?
If you are using code space for long term variable storage then (IIRC)
you can selectively disable protection for portions of the code space -
just make certian your code never jumps to anywhere in that space.
Alternately make the circuit upwards compatible for an 18f chip, and
include in the cost a free one-time hardware upgrade. Then don't change
the code until the new chip comes out.
> >I'm debating whether to remove RB6 and/or RB7 in that case to
> >thwart "enthusiastic amateurs", once the code has been finalised
> >
> >
> But, but... Information *wants* to be free! Your program _yearns_ to
> be extended!
So, set it free and if it doesn't come back it wasn't yours to keep ? ;-)
A fine sentiment for smoochy feel-good movies, not for valuable
data unfortunately
> All kidding aside, any chip missing pins is just screaming to be hacked.
> Might make the enthusiastic even more so.
>
> But then, if the code is finalised then you don't need to update the
> chip, right?
The data needs to be re-written on a regular basis and stay very very
confidential. Only the program code stays the same. There will be
safeguards in place to detect any tampering with the PIC housing,
and if tampering is detected renders the data valueless. IOW, the data
has meaning unless it's read by anyone authorised, so there is liltle
point in hacking and absolutely nothing to gain. Removing ICSP pins
is just one of the protection measures in place
> Alternately make the circuit upwards compatible for an 18f chip, and
> include in the cost a free one-time hardware upgrade. Then don't
> change the code until the new chip comes out
For this prototype I have to stick with the F877 (time constraints) but
in future I would consider the 18F series
>
>
>On Sun, Jul 14, 2002 at 06:33:42PM +1200, Jinx wrote:
> > Do I assume correctly that Flash memory on a 16F877 can't
> > be enabled for internal writes and disabled for external reads
> > at the same time ? (Table 4-1 of F877 manual). Is it just that
> > simple or is there a workaround ?
I believe the 16F87xA family resolve this problem as they have
separated code protection and write protection into different
config bits. I have one here and I will be testing this later today
I hope.
>It is just that simple. An unfortunate side effect that one extra bit in the
>config register could have resolved.
>
>BTW from my recent reading of of the 18F series chips, the config register
>is readable and writable programmatically. So it should be possible to to
>only disable code protection under program control. So for example one could
>send an encrypted stream with an authorization code. The internal program can
>temporarily disable code protection, write the new code, then reenable it.
>
>Seems to be workable.
Nope. The 18Fxxx can program its own config area but it cannot remove code
protection as it cannot write a CP bit from '0' to '1'
See DS39564A- section 19.4.1
In any case the 18Fxxx can write to code protected areas if the write protect
bits allow it so you can have a bootloader within a code protected 18Fxxx.
>> Do I assume correctly that Flash memory on a 16F877 can't
>> be enabled for internal writes and disabled for external reads
.> at the same time ? (Table 4-1 of F877 manual). Is it just that
>> simple or is there a workaround ?
>It is just that simple. An unfortunate side effect that one extra bit in
the
>config register could have resolved.
Well actually it wouldn't resolve it, because there could still be an
internal read from downloaded code. You could only resolve it if the memory
could be write only, but that would stop the code from doing self checks at
start up. This problem will surely still exist on the 18F series you
mention, for the same reason.
>Well actually it wouldn't resolve it, because there could still be an
>internal read from downloaded code. You could only resolve it if the memory
>could be write only, but that would stop the code from doing self checks at
>start up. This problem will surely still exist on the 18F series you
>mention, for the same reason.
18F series has a configuration register that enables read protection
(CONFIG5L), and another configuration register enables table reads
(CONFIG7L). So your code could do self checks at start up using table reads,
while it is read protected.
>So your code could do self checks at start up using
>table reads, while it is read protected.
But surely this would still allow someone to download a rogue piece of code
to read out your code, even though you have taken every possible precaution
to prevent this happening.
mitvma.mit.edu with SET PICList DIGEST in the body
