Write-protect boot and program memory

[kgng97ccs]

Environment: PIC18LF46K22, MPLAB 8.92, CCS v5.115

I am trying to resolve an issue I am facing. I am using a bootloader and a serial loaded application on the PIC18LF46K22.

Bootloader: #fuses WRTB, NOWRT
Application: #fuses WRTB, WRT

The compiled application .lst file shows that the fuses are configured correctly:
Word 6: A000 (WRTB write-protected, WRT0 to WRT3 write-protected).

However, I found that after I bootloaded the application and read back the Config registers using read_program_memory() in my application runtime, I found WRT0 to WRT3 blocks are not write-protected.
Word 6: A00F (WRTB write-protected, WRT0 to WRT3 not write-protected).

What I want to do is to write-protect the boot memory in the bootloader, so that I can still load the application in bootload mode (#fuses WRTB, NOWRT). However, I want to write-protect the entire program memory and boot memory once my application has been loaded (#fuses WRT, WRTB). The next time I enter bootload mode I want the fuses to revert to WRTB and NOWDT, so that I can bootload a new application again.

How can I achieve this?

[Ttelmah]

What you do, is code protect, write protect and read protect the bootloader.
Then enable code protection for all the memory. Understand that code
protection prevents _external_ read and writing The bootloader can
still write to code protected memory, unless EBTR bits are set.
Understand that with the CP bits set the memory is already protected
from external reading and writing.
Once any proaction fuse is set, it cannot be turned off without a full
chip erase. They would be pointless if you could turn them off from the
bootloader or code.

[kgng97ccs]

Thank you, Ttelmah.

My main concern is not about prevention from external reading and writing, but I have observed some cases of corruption of program memory during runtime. The device can be exposed to extremely low temperatures (-45°C) and being battery-operated, it is possible that the battery voltage drops at such low temperatures. The PIC (PIC18LF46K22-I/MV) is running off a 3-V LDO supplied by a 3.6-V, 1.6-Ah lithium primary cell. The battery is rated to -60°C.

These are the current fuses in my application:

[Ttelmah]

OK. The first thing is to make sure that the bootloader write code cannot
be called when the temperature is outside the allowed range. Is it possible
to have temperature sensing in the project?. Remember there are things
like diodes that can give a rough guide to temperature. So long as your
bootloader code cannot write unless the temperature and supply are
acceptable, this removes the problems with writes.
The article you point to is dealing with mainly high temperatures not low,
however brownout is vital on any battery driven application, and obviously
becomes more likely at low temperatures. Also having a POR delay is
always good practice, but won't affect the system once running, so is
unlikely to affect a running system.
Have you considered the RF part of that article?. I've seen RF problems
becoming more and more common on the modern lower voltage PICs.
If the system is getting to -45C, then this is outside the operating range
for the processor. -40C is it's minimum. You might talk to Microchip, on
some chips they do offer a M range device, but they don't list it for this
device.

[kgng97ccs]

Thank you, Telmah.

In the field, the bootloader mode is unlikely to happen in normal use, as that would require a combination of MCU reset and external button press. There is a temperature sensor on board, and I may try to activate it to see if it helps too. Loading of the application is via UART, which is not accessible to the user.

Thank you for pointing out the RF portion, which didn't occur to me until now. There is an NFC interface on the device, and the power generated by the NFC reader may affect the MCU. This interface is used daily frequently by the user.

Thank you for sharing your insights and information on the M range devices.