CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to CCS Technical Support

Reading back code from 18F6722 with code protect on

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
icefield



Joined: 09 May 2005
Posts: 20
Location: Canada

View user's profile Send private message

Reading back code from 18F6722 with code protect on
PostPosted: Thu May 10, 2007 6:03 pm     Reply with quote

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

View user's profile Send private message

PostPosted: Thu May 10, 2007 11:32 pm     Reply with quote

You're reading something in the "Configuration and ID Space", which
begins at address 0x200000. For more information, see these links:

Programming specification for 18F6722:
http://ww1.microchip.com/downloads/en/DeviceDoc/39643B.pdf

Keil page on Intel Hex file format:
http://www.keil.com/support/docs/1584.asp?bhcp=1
Guest








PostPosted: Fri May 11, 2007 12:10 am     Reply with quote

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

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

View user's profile Send private message

PostPosted: Fri May 11, 2007 7:33 am     Reply with quote

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.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group