how to recover code of PIC16C57

moonnightingale

·I am stuck with problem of microcontroller.I have a microcontroller which is installed on PCB. This is basically power PCB. The microcontroller is Microchip PIC16C57.·
I have read its code and burnt in new microcontroller having same model and number. But when i installed it on PCB and when PCB was installed on machine, the output was not desired. What else can go wrong. I am having Universal Programmer 3000u.
I am·attaching·the Code file· The original microcontroller was burnt by some one else. Is there any hidden encryption which stops to work new microcontroller work properly. some body saw my code and told me that it is code protected. Can u kindly tell me steps to recover my code.
Kindly comment.
Thanks

Mike Green

If it is code protected, you can't recover the code in any reasonable fashion. There's no "hidden code". Once the code protect bit is set, it's impossible to read the program using a chip programmer. There's no way around that. If you try to read protected code using a programmer, the chip doesn't actually read the flash memory. It supplies some other information instead.

There are companies that will take your PIC16C57, remove the plastic over the chip itself using solvents, and read out the contents of the flash EEPROM using an electron beam probe to read the charge stored in each bit cell. This is very very expensive with no guarantees of success

moonnightingale

I have heard some methods in which certain volatges are applied to special pins and then code protection is broken.
Any comments abt that

Mike Green

Maybe you're thinking about how many older chips work with programmers. You supply +12V (or something similar) to a particular pin to get the chip into programming mode. You can't "break" code protection that way. You can re-program the chip though with a new program.

There's no way to "break" code protection other than what I described. That method requires special expertise and equipment and is very expensive, but doable commercially.

soshimo

Mike is right. Certain FUSEs, when set, are non reversible. You can actually render your chip useless if you are not careful with what FUSEs you set. The same is true for both AVR and PIC (and probably most other ucontrollers, I just have experience with those two). You typically set the CP FUSE when you are ready to deploy your solution, not during development (or integration testing which is when you found your problem). Hopefully you backed up your code and you should be able to just restore your backup and burn a new chip for testing (this time don't set the CP bit). If you don't have the source then you are out of luck.

Stanley Frederickson

I took a look at your code dump and did notice a few things. I might be wrong but I think the 16CF7 is a 2k-word part and that would probably explain why almost every byte after address 0x1000 is set to 0xFF. The weirder thing I noticed is that even in the first half of this dump (the first 2k words), the odd bytes are always 0x00 so it is doubtful that you have a good read. Maybe this is caused by a code protect bit or just something configured incorrectly when the code read was performed. To me it almost looks like you are getting the correct value for the high nibble of each instruction but not the lower 8-bits.

In addition to duplicating the code, you will probably need to make sure that the FUSE settings match as well.

moonnightingale

Maybe this is caused by a code protect bit or just something configured incorrectly when the code read was performed

Can u kindly explain this to me. You want to say that it is possible that code is not protected and i am making certain mistake while reading from MCU. Might be my seetings of software are not correct. This is PIC16C57 and i am using Unversal Programmer 3000u by Xeltek.

Can u give me some solution. I am desparate to get my code back

Stanley Frederickson

I don't have any experience with your particular programmer...actually I don't have any experience with the PIC16C57 either. I do have some experience at looking at my own SX28 and SX48 object dumps and there are some similariites between those and what I am seeing with your code file with the differences that I noted before.

If you are already very experienced with your programmer then you can ignore this paragraph. If not, you might want to try an experiment to see if you are using the programmer to read out the code correctly. Program a new chip with some code that you have written yourself to do something simple like blink an LED. Program the chip and make sure it works as expected. Then use your programmer to read out the code and see if it has the odd issues that I saw in your previous dump. You can also try programming a chip from this code dump that you just read out. If this works after having followed the same steps as you used for reading the other chip then I think it would definitely point to the code protect bit being set and not usage of the programmer.

moonnightingale

Thanks Stanley.I will try this and let u know. There might be some error in reading code.

LoopyByteloose

www.PIClist.com might be helpful. The same guy runs www.SXlist.com.

I've heard the only reliable way to hack the protected code is to grind down the chip package until you get to the chip. Then etch the chip with various chemicals and read the code with a rather good microscope.

I have a bunch of SX18 chips that I treasure as they fit into the same sockets at 18 pin DIP PICs (but they require a SX programer). It seems that the PIC16c57 may be pin compatible with the SX28. One can migrate over to that if all else fails.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Ain't gadetry a wonderful thing?

aka G. Herzog [noparse][[/noparse] 黃鶴 ] in Taiwan

Post Edited (Loopy Byteloose) : 7/24/2010 4:45:33 PM GMT