cancel
Showing results for 
Search instead for 
Did you mean: 

RDP level2 isn't compatible with WRP

S-.1
Associate II

Hello,

please I need a confirmation about RDP level2 and WRP combination on stm32g031 chip.

Based on RM0444.Rev5 Table 19, if I use my own bootloader and I write-protect the flash sectors, I have to avoid activating RDP level2 or I'll loose the opportunity to update any firmware (application and/or bootloader itself) even from inside the microcontroller.

Is that correct?

If it was correct: so why, generally speaking, one should go with RDP level 2 when RDP level 1 is enough to prevents useful data to be read-out from the main flash?

Just to avoid any firmware update from the outside world?

 

Thank you

1 ACCEPTED SOLUTION

Accepted Solutions
Jocelyn RICARD
ST Employee

Hello @S-.1 ,

OK I get your point now.

Using write protection on application is not common when you have an update capability.

Your understanding is correct.

In order to address such flash unwanted write, you have different solutions

1) You can have a trick to "lock" the flash until next reset by providing wrong key to unlock. In that case you need to handle the hardfault that is resulting from this. The drawback is that you cannot write any data in the flash (like configuration data you are mentioning)

2) use MPU to protect application flash area. This can protect against writing in unwanted parts but not from erasing, except if you also protect FLASH registers, and unprotect once needed.

3) Just use a "robustified" flash driver that check what address is accessed.

Best regards

Jocelyn

View solution in original post

4 REPLIES 4
Jocelyn RICARD
ST Employee

Hello @S-.1 

I'm not sure what make you think this in this table. Maybe you are mixing with system bootloader ?

If you use your own bootloader, the use of write protection on the flash area where this bootloader is located is a good practice indeed. And setting RDP Level 2 will ensure that write protection cannot be removed and that your bootloader will always be the first code to execute after reset.

So, no issue using RDP Level 2 in your setup.

Besides, on the STM32G031 you have the securable memory area that may be used in your setup.

Setting the chip to protect your bootloader in this securable area will give a higher level of security by making this flash memory location unreadable from application.

Also, using BOOT_LOCK + RDP Level 1 will automatically disable the JTAG at boot. This allows having a chip that stays in RDP Level 1 (if this is something you really need)  but that cannot be connected with JTAG.

The embedded firmware can reenable the JTAG connection upon specific trigger under control of embedded firmware to give access to debugger. Can be useful in development or for field return analysis to perform a regression.

So, you have many options !

Best regards

Jocelyn

Thank you for your reply.

 


I'm not sure what make you think this in this table. Maybe you are mixing with system bootloader ?

RM0444_table19.jpg

 

If you use your own bootloader, the use of write protection on the flash area where this bootloader is located is a good practice indeed.


Yes, surely.
And I usually also apply the write protection on the flash area where the user-application firmware is located.
Specially if one or more pages of main flash are used to store some configuration data.
In this way the user-application is protected against unwanted writes due to a problem while the flash page with configuration is erased/written.

As table 19 says that option bytes on RDP level2 can't be written nor erased, my conclusion was that one can't use RDP level 2 if he/she wants to apply WRP over user-application flash area too. This is because, with RDP level2, WRP can't be removed so the user-application firmware upgradeability is lost.

So the main two options now are:

  1. BOOT_LOCK + RDP Level 1 (+ Securable Area) in order to preserve the ability to enable/disable WRP
  2. RDP Level 2 + WRP on bootloader area only (user-application is still internally upgradeable but slightly 'weaker' because can't be write-protected against unwanted writes)

Did I understand correctly?

Thank you

Jocelyn RICARD
ST Employee

Hello @S-.1 ,

OK I get your point now.

Using write protection on application is not common when you have an update capability.

Your understanding is correct.

In order to address such flash unwanted write, you have different solutions

1) You can have a trick to "lock" the flash until next reset by providing wrong key to unlock. In that case you need to handle the hardfault that is resulting from this. The drawback is that you cannot write any data in the flash (like configuration data you are mentioning)

2) use MPU to protect application flash area. This can protect against writing in unwanted parts but not from erasing, except if you also protect FLASH registers, and unprotect once needed.

3) Just use a "robustified" flash driver that check what address is accessed.

Best regards

Jocelyn

Nice trick the one you presented, which I hadn't thought of!

Thank you for all your suggestions.

Best regards