Andy Kunz wrote:
>
> At 11:44 AM 5/27/97 -0600, you wrote:
> >I don't remember this particular question being part of the thread a few
> >weeks back, and the archive site isn't responding.
> >
> >I programmed a windowed 16c74 (I know it's not recommended and I don't
> >care if I have to throw it out or not) with code protection enabled.
> >I'm still able to read and save the hex file using the PICStart and its
> >associated PC software.  The saved hex file is about 20% smaller than
> >the original hex file I programmed into the device, so I assume that
> >it's corrupted in some way.
> >
> >The question(s): is there any reason to be concerned?  Is any of the
> >code recoverable from the hex file I downloaded from the protected
> >device?
>
> It could be that the original file is not sequential, and/or that the lines
> are not "full" in the original.  This is not uncommon if you have a lot of
> "ORG" statements or are using C.
>
> When you read the chip back, it read it sequentially, with long, uniform
> lines.  This resulted in less overhead, hence the size difference.
>
> Probably no reason to be concerned.  What you should do is Verify the
> contents of the files against one another (assuming the read-back one is
> not all zeros).
>
> Without more data, no-one can answer properly.  The question is, Does it work?
>
> Andy
>
Further info: I _am_ using a C compiler.  The original embedded code
works fine in a code protected device.  I can download the code from the
protected device and program it into a second device.  That code does
_not_ run.  If nothing can be disassembled from the downloaded protected
code, that's fine.  I guess I'm surprised that I can download anything
at all from a protected device (instead of just FFs or 00s).

Paranoidly yours, Matt