CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to CCS Technical Support

Write-protect boot and program memory

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
kgng97ccs



Joined: 02 Apr 2022
Posts: 99

View user's profile Send private message

Write-protect boot and program memory
PostPosted: Tue Jan 21, 2025 1:55 am     Reply with quote

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



Joined: 11 Mar 2010
Posts: 19613

View user's profile Send private message

PostPosted: Tue Jan 21, 2025 4:26 am     Reply with quote

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



Joined: 02 Apr 2022
Posts: 99

View user's profile Send private message

PostPosted: Tue Jan 21, 2025 10:10 pm     Reply with quote

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:
Code:
#fuses WRT, WRTB, NOCPB, NOLVP, WDT_SW, WDT4096, LP, NOBROWNOUT, NOPROTECT, NOCPD, FCMEN, NOIESO, NOPUT, STVREN, NODEBUG, NOMCLR, NOXINST, NOPBADEN

My application code does not have instructions to write to EEPROM or program memory.

It looks like this may be a known problem (see link below), and Microchip has suggested enabling the Power-up Timer and Brownout Reset. I would like to seek your advice.

It is difficult for me to replicate this issue as it happens randomly in the field.

Link: https://microchip.my.site.com/s/article/Flash-Memory-Corruption
Ttelmah



Joined: 11 Mar 2010
Posts: 19613

View user's profile Send private message

PostPosted: Wed Jan 22, 2025 1:34 am     Reply with quote

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.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group