Searching \ for '[PIC]: Code protect allowing most of code to be re' 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=pic
Search entire site for: 'Code protect allowing most of code to be re'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Code protect allowing most of code to be re'
2000\11\22@043810 by Lorick

flavicon
face
Was I witnessing a coincidence or does this make sense?  When I've tried to
test-read the contents of a code protected PIC in the past, I've gotten all
0's where the code would otherwise be, but when I read the code back from my
first 2 code protected 16C505's, I got the usual message that the device is
protected and memory may not be valid, but I still saw most if not all of my
code get dumped...

I compared the dump to the original hex size in the ram window and noticed
that it seemed to clearly show the code up to around 0x040 and then it
showed still non-zero stuff, but somewhat scrambled.  I'm not sure if one of
the chips gave all the code or not.

So I made a mental note to try setting org 0x040 instead of 0x000 the next
time, which would be right now, and see what happens...this time when I read
back the code, it did the usual, giving me all 0's starting at 0x040, and
leaving the unprogrammed F's from 0x000 up to there of course...but no code
was read, scrambled or otherwise this time from the code protected 16C505.

So is there something I don't know here, or was it a coincidence that the
last day I was reading code in and today I'm getting the usual results or
does it have something to do with changing my ORG?


God help me if this is "in the manual"...I am asking without checking, I
admit!

--
http://www.piclist.com hint: To leave the PICList
spam_OUTpiclist-unsubscribe-requestTakeThisOuTspammitvma.mit.edu


2000\11\22@063909 by mike

flavicon
face
On Wed, 22 Nov 2000 04:22:23 -0500, you wrote:

{Quote hidden}

It is.
On many (all?) of the low-end chips there is an unprotected area near
the start, intended for programming IDs, calibration data etc. I'm not sure about the current devices, but on the first 16c5x parts,
the values read from a protected part were the XOR of the 3 nibbles of
each word - this allowed secure devices to be verified and identified
but not copied. They have messed around with this on some subsequent
parts - not sure what the current state of play is.
--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestKILLspamspam@spam@mitvma.mit.edu


2000\11\23@043003 by Andrew Warren

face
flavicon
face
Lorick <PICLISTspamKILLspamMITVMA.MIT.EDU> wrote:

> Was I witnessing a coincidence or does this make sense?  When I've
> tried to test-read the contents of a code protected PIC in the
> past, I've gotten all 0's where the code would otherwise be, but
> when I read the code back from my first 2 code protected 16C505's,
> I got the usual message that the device is protected and memory may
> not be valid, but I still saw most if not all of my code get
> dumped...
>
> I compared the dump to the original hex size in the ram window and
> noticed that it seemed to clearly show the code up to around 0x040
> and then it showed still non-zero stuff, but somewhat scrambled.

Lorick:

The old 12-bit PICs (16C5x, 16C505, etc.) use a different copy-
protection scheme than the newer PICs.  When you code-protect a 12-
bit PIC, addresses 0x00-0x3F are NOT protected; you can still read
and write to them.  Addresses 0x40+ ARE protected (more or less);
when you read from them, you get 0x00n, where "n" is the 4-bit sum of
the three nibbles in the memory location.

-Andrew


=== Andrew Warren - .....fastfwdKILLspamspam.....ix.netcom.com
=== Fast Forward Engineering - San Diego, California
=== http://www.geocities.com/SiliconValley/2499

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


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