Except when this automatic switchover is actually not broken (always check your errata
).
I'd be glad to get prooven otherwise, but so far it does not seem to be the case.Cited from PIC18F47J53 datasheet (DS39964B):
28.1.1 CONSIDERATIONS FORCONFIGURING THE PIC18F47J53 FAMILY DEVICES
Unlike some previous PIC18 microcontrollers, devices of the PIC18F47J53 family do not use persistent memory registers to store configuration information. The Configuration registers, CONFIG1L through CONFIG4H, are implemented as volatile memory. Immediately after power-up, or after a device Reset, the microcontroller hardware automatically loads the CONFIG1L through CONFIG4L registers with configuration data stored in nonvolatile Flash program memory. The last four words of Flash program memory, known as the Flash Configuration Words (FCW), are used to store the configuration data.
When creating applications for these devices, users should always specifically allocate the location of the FCW for configuration data. This is to make certain that program code is not stored in this address when the code is compiled. The four Most Significant bits (MSb) of the FCW, corresponding to CONFIG1H, CONFIG2H, CONFIG3H and CONFIG4H, should always be programmed to ‘1111’. This makes these FCWs appear to be NOP instructions in the remote event that their locations are ever executed by accident. The four MSbs of the CONFIG1H, CONFIG2H, CONFIG3H and CONFIG4H registers are not implemented, so writing ‘1’s to their corresponding FCW has no effect on device operation.
To prevent inadvertent configuration changes during code execution, the Configuration registers, CONFIG1L through CONFIG4L, are loaded only onceper power-up or Reset cycle. User’s firmware can still change the configuration by using self-reprogramming to modify the contents of the FCW. Modifying the FCW will not change the active contents being used in the CONFIG1L through CONFIG4H registers until after the device is reset.
And yes, this includes program memory readout protection bits.
During flash write, write lock sequence mechanism is used (0x55; 0xAA write to EECON2) - which is the first safeguard against unintenional changes to the (program) memory contents, but inherently has to be disabled due to bootloader trying to achieve exactly this.
IOLOCK and one-way lock for some config bits are valid only for RAM loaded values to serve as a safeguard agaisnt unintentional changes during runtime on the RAM registers stored values.
EDIT:
Thanks for stubble RTFM suggestion.
After re-checking the datasheets of both devices troughly, I managed to find the missing bit (pun intended) in the CONFIGx registers.
It is CONFIG4L -> WPCFG , wich
must be cleared along with CONFIG4H -> WPDIS, otherwise all written above stands true.
One should be cautious as
this bit invokes protection over whole last page of flash memory, not just the CONFIGx preset values. (This might make for some nasty bug in future, better to prohibit code placement in the last page in linker settings to be sure). So in the end all said previously - except for the soft-checks inside booltoader (when that particular bit is cleared) - holds true.