View previous topic :: View next topic |
Author |
Message |
icefield
Joined: 09 May 2005 Posts: 20 Location: Canada
|
Reading back code from 18F6722 with code protect on |
Posted: Thu May 10, 2007 6:03 pm |
|
|
I've been playing with code protection in order to understand it. I have all CPx bits clear (code-protected) as well as CPB clear. When reading the code back out with the CCS ICD-U40, most of the code reads as zero (to be expected with code protection on), but there are two odd things:
(1) The .HEX dump file produced by the ICD software seems to indicate that the dump begins at memory location 0x020000 rather than 0x000000 (see second line of .hex file snippet below)
(2) There are non-zero values between addresses 0x0-0x200 (or perhaps it's 0x020000-0x020100)
(3) This "corrupted" data between 0-0x100 (or whatever) also appears when dumping code from a chip with no code protect (in which case everything past 0x100 matches the code in the .hex file used to program the part).
:020000040000FA
:020000040020DA
:10000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF00
:10001000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF0
:10002000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE0
:10003000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFD0
:10004000F5680C0000000C0E806E01C0D3FF801E0E
:1000500081B0FDD7806802C0D3FF0000000081A4FA
:10006000926881A20300806A92688A360400FDD7F4
:10007000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF90
:10008000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF80
:10009000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF70
:1000A000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF60
:1000B000FFFFFFFFFFFFFFFFFFFFFFFFFFFF61FFEE
:1000C000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF40
:1000D000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF30
:1000E000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF20
:1000F000FFFFFFFFFFFFFF01FFFFFFFF727373743E
:1001000000000000000000000000000000000000EF
....etc.
So, my questions are what is this data and where does it come from? Given that in non-code protect, everything looks good past 0x100, it must be reading from 0x100 and not 0x020100 as the dump suggests.
But, why can I read it with code protect on? And where are my interrupt vectors? The data in the 0-0x100 range of the dump does NOT match the original .hex file used to program the part.
Thanks for any tips.... |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
|
Guest
|
|
Posted: Fri May 11, 2007 12:10 am |
|
|
Hmmm, yes. I note that is is direct output from the ICD software provided by CCS, so it is not really "me" reading this from the chip. To say it is the configuration area is not the complete answer since past address 0x100 (with no change in the high address byte via a 04 Intel hex command) we suddenly get a program dump (which I presume is not stored in a 128k configuration area ).
I only gave a snippet of the dump,... it goes on and on past 0x100 as one expects - it's just the first 0x100 bytes that are strange.
Again, does anyone know why I am getting strange results for the first 0x100 bytes of the CCS program download?
I expect all zeros when protection is on and the actual code when it is off. In both cases, I get the data shown below, which does not match either.
Cheers,
Erik |
|
|
SherpaDoug
Joined: 07 Sep 2003 Posts: 1640 Location: Cape Cod Mass USA
|
|
Posted: Fri May 11, 2007 7:33 am |
|
|
Anonymous wrote: | I expect all zeros when protection is on and the actual code when it is off. In both cases, I get the data shown below, which does not match either.
|
I am not sure about newer PICs but the older ones (16C54) when protected would give a scrambled output. You could verify the code was good by comparing the scrambled output with the scrambled output of a known good chip. But there was no way to un-scramble to get runnable (stealable) code. _________________ The search for better is endless. Instead simply find very good and get the job done. |
|
|
|