I have a dsPIC33 series micro that I believe is "code protected" because when I try to read back the data on the micro, I get all zeros using a PICKit2 programmer. The PICKit2 programmer is one I purchased from Microchip and I know it works as I've programmed other micros with it.

I'm fairly new to the field of embedded and micro and I'm trying to learn. So various devices I have in my possession, I've successfully tapped the micro and read it's code but the dsPICs I'm not able to get anything but zeros.

I have two questions:

  1. If the micro is, in fact, code protected then is there a way to unprotect and extract the image? According to Microchip's web site it states it might be possible but such methods involve subjecting their products beyond their normal operating limits. I'm guessing they are referring to messing with the voltage levels and what not.

  2. What is actually going on when I code protect a micro?

As an interesting side note, this particular dsPIC33 I have is programmed in the clear over the USB bus. I could, theoretically, sniff the output of the FTDI chip that sits in front of the Micro and get the code that way but I'm more interested in knowing if reading back all zeros means the chip is code protected and, if so, if it's possible to break the protection, and how this protection is accomplished.

I plan on working on a small gaget as a proof of concept and I would like to ensure the code I write and flash in my own device is protected and so I'm trying to understand how secure this really is.

And for the purist out there, I do realize anything can be broken into -- I'm just trying to see what kind of effort is involved in this particular case.

The exact part number is dsPIC33FJ256GP710A from Microchip.

Thanks for reading!


1 Answer 1


The code protect is (optionally) set using a configuration bit when programming. If not set then you can read back as normal, if set you read back all zeros and the only way to clear it is by erasing the chip.
The bit will control something like a couple of AND gates to control access to the flash memory lines - this page at Flylogic discusses the security bit structure of a PIC16 (how to defeat it here)
To defeat it usually requires access to the die itself - e.g decapping of the chip, a powerful microscope and some idea of what to look for.
This link describes the process of clearing the security bit on a PIC18F.

  • \$\begingroup\$ Thanks for the links -- very interesting. I also have a PIC18F2480 that MPLAB says is code protected too. When I use the debugger to read program data and then view the program memory, the first instruction reads: EF6B GOTO 0x1ad6 and between 0000 and 0x1ad6 is some data but at 0x1ad6 is nothing but zeros (NOPs). \$\endgroup\$
    – Eric M
    Oct 1, 2011 at 2:02
  • \$\begingroup\$ The first instruction is the reset vector, and I think on that chip the first bit of flash is for a bootloader. There are usually a few protection bits for different areas of memory, so it's probably the case that the bootloader bit has not been set but the other areas have. The datasheet will give you the precise details. \$\endgroup\$
    – Oli Glaser
    Oct 1, 2011 at 2:46
  • \$\begingroup\$ If the Code Protect bit is set, and you attempt to read the program memory, does MPLab X report the bit's state, vs. just returning FFs? \$\endgroup\$
    – ndemarco
    Mar 24 at 15:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.