Internal flash memory locking (FLASH_CR->LOCK) and write protection (nWRP) - Why does the latter exist?

[arnold_w]

I am working with the STM32F446 Nucleo-144 development board. I understand that there are 2 ways to prevent the flash from being unintentionally erased/overwritten:

1. LOCK-bit in register FLASH_CR

2. nWRP-bits in the option bytes

Why has the second method been introduced, why isn't locking enough? Could someone please give some examples of when #2 should be used?

[waclawek.jan]

nWRP protect per-sector and this is a non-volatile setting (ie. set at programming time, regardless of what's in the software); LOCK-bit protects against *any* inadvertent write and can be unlocked in software.

nWRP is typically used when some portion of FLASH shall not be overwritten (A) and others yes (B), e.g. A=bootloader B=application; or A=whole firmware and B=changing data stored by firmware in portion of FLASH.

JW

[arnold_w]

Let's assume my code is perfect (never does a write accidentally), do I then need nWRP? For example, does nWRP protect the data better if the power supply is unreliable or there are ESD-problems?

[waclawek.jan]

This is an implementation detail I don't believe anybody is going to find out and publish here... I'd say yes, but IMO the difference would be marginal (i.e IMO the likelihood of FLASH corruption due to "glitch" is say 1/1000000 without the lock and 1/1000001 with the lock; the numbers are not related to reality in any way, pulled out of thin air just to illustrate my point).

JW

[arnold_w]

Ok, thanks, then I'll only use the lock and I can still continue to sleep well at night.