Seeking Effective Flash Protection Methods for 54L05 Chip

[Ozzy]

Hello everyone,

I am currently working on implementing the flash protection feature for the 54L05 chip. My objective is to safeguard the code storage area from unintended erasure or overwriting during program execution. I have attempted to use the fprotect_area function for this purpose. However, upon verification, I found that the protected area can still be erased or written to. Could anyone share some ideas or alternative solutions to achieve effective flash protection?

P.S. The SDK version I am using is 3.0.0.

Thank you in advance for your valuable input!

[Hieu]

Hi Ozzy,

I ran a test based on the soc_nrf_flash sample and cannot see the same issue. If I use fprotect to lock the area of flash that the sample will try to write, the sample will crash as expected. Without the lock, the sample would run to completion.

Could you please give more details about your setup? Or perhaps, give me a minimal project that can reproduce the issue?

Attached is my test project for my reference.

c347813_250703_01.zip

Hieu

[Ozzy]

Hi Hieu,

Thank you for your time and assistance. I have another question regarding the 54l05. What is the maximum address length that the fprotect_area function can protect? Are there any restrictions on the start address and the length of the protected area?

Thank you for your reply!
Ozzy

[Susheel Nuguru]

Hi Ozzy,

I will try to answer while Hieu is away. I am not sure if I understood the question right but if you are asking about the maximum flash size that can be used with fprotect_area and its alignment restrictions then both start and length address needs be multiple of 4KB (0x1000) and the whole RRAM can be used to be protected (using address is 0x0 and length as 0x80000)