cancel
Showing results for 
Search instead for 
Did you mean: 

Dynamic use of WRP (in STM32WBx5) ?

OliM
Senior

To secure my bootloader against erroneous writes from the application I want to enable write protection on it. But since for some things the bootloader needs to modify data inside its partition (security counter update and key invalidation), I can not just enable write protection and be done with it. I would need to disable it at some point and reenable it again. Best case without rebooting in between.
Now what I am trying to understand ist when the WRP setting actually takes effect, so how dynamic I can use it. The reference manual says:

"To validate the WRP options, the option bytes must be reloaded through the OBL_LAUNCH
bit in Flash memory control register"

But validation is not enabling. So when can the register be written and when does the change take effect?

I think my question is quite similar to the following, but that was never solved
https://community.st.com/t5/stm32-mcus-security/about-read-out-protection-write-protection/m-p/162290

1 ACCEPTED SOLUTION

Accepted Solutions

Hello  @OliM ,

to summaries WRP can be set either by software or using cubeprogrammer but will need OB lunch function which will trigger a system reset.
Regards

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

View solution in original post

8 REPLIES 8
STea
ST Employee

Hello @OliM ,

The WRP settings take effect after the option bytes are reloaded. This can be done by setting the OBL_LAUNCH bit or after a power reset. The new WRP settings are not applied immediately upon writing to the option bytes. They are applied only after the option bytes are reloaded.

You can dynamically enable and disable WRP by modifying the option bytes and then reloading them using the OBL_LAUNCH bit. This process does not necessarily require a reboot, but it does require the option bytes to be reloaded to apply the change.
Regards

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
OliM
Senior

Does this also mean option byte unlocking sequence needs to be done to write WRP?

STea
ST Employee

Hello @OliM ,

indeed, the sequence will need to be as follows:

  1. unlock flash and unlock OB 
  2. program OB
  3. lock OB THEN FLASH

See this article for more details How to program STM32 Option Bytes with the HAL API - STMicroelectronics Community

Regards

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Hm, the reference manual also states


Setting OBL_LAUNCH generates a reset so the option byte loading is performed under
system reset.


Doesn't this contradict the following?


You can dynamically enable and disable WRP by modifying the option bytes and then reloading them using the OBL_LAUNCH bit. This process does not necessarily require a reboot,

Hello @OliM ,

I meant that the user does not need to reboot the system but still the the HAL_FLASH_OB_Launch() causes a system reset and therefore will never return. see section 1.1 of the article. 
Regards

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
OliM
Senior

So for WRP changes to take effect, the system needs to reset. In my mind that's a long way from dynamically enabling/disabling the feature, since it is actually static during runtime.
But at least I now know that this is the case and can try to work from there.

Hello  @OliM ,

to summaries WRP can be set either by software or using cubeprogrammer but will need OB lunch function which will trigger a system reset.
Regards

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
OliM
Senior

I think I still have one more question:
Since WRP is an option byte, that also means it is no longer writable in RDP level 2, right?