The PIC's (PIC16F87XA) firmware can be programmed by an external programmer and have the Flash Program Memory Code Protection bit set or cleared.

How can the firmware check that the protection is enabled?

The configuration word (address 2007h) has a Flash Program Memory Code Protection bit (bit 13).

CP: Flash Program Memory Code Protection bit
1 = Code protection off
0 = All program memory code-protected

The configuration word appears to be inaccessible for writing by the firmware per PIC16F87XA 14.1 Configuration Bits.

It is important to note that address 2007h is beyond the user program memory space which can be accessed only during programming.

As there is no need for the firmware to write the configuration word, loss of write access is not important.

The configuration word also appears to not have read access per the same 14.1.

Is there any way for the firmware to read the Flash Program Memory Code Protection bit, a copy of it, checksum/parity the firmware including the configuration word, somehow assess or test if the firmware is protected?

One can re-connect an external programmer and attempt to read the firmware and either succeed or fail as a test. Yet that is not the firmware itself doing this assessment.

I suspect there is no published solution - I hope I am wrong.

  • \$\begingroup\$ what happens if firmware tries to read protected memory ? \$\endgroup\$ – jsotola Nov 29 '17 at 4:08
  • \$\begingroup\$ @jsotola My calls to a function that implements 3.5 Reading Flash Program Memory to read Flash Program Memory works as expected for low addresses yet does not yield expected results for x2007. I will review its assembly to see details of how it might be failing. \$\endgroup\$ – chux Nov 29 '17 at 4:20
  • \$\begingroup\$ i checked the data sheet. internal reads of the flash memory are not inhibited, only external reads are inhibited. so, there appears to be no way internally to determine the protection bit state. \$\endgroup\$ – jsotola Nov 29 '17 at 5:01
  • \$\begingroup\$ @jsotola Thank for that info. I reviewed code assembly. Tested: When code uses a 16-bit address above 0x1FFF, the data read via EEADR, EEADRH, EECON1:EEPGD:1, EEDATA, EEDATH, is as if the upper 7 bits are 0. Addresses above the range of the respective device will wraparound to the beginning of program memory (pdf 3.0). So no success that route. \$\endgroup\$ – chux Nov 30 '17 at 2:39

Your Answer

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

Browse other questions tagged or ask your own question.