STM32H523 Flash write protection in CLOSED state?

[andy]

Hi

I have a design using STM32H523 and I've managed to ensure that my firmware switches PRODUCT_STATE to 'Closed', and sets a valid debug password, the first time it runs. This works well.

In the Flash I have a bootloader, application, and configuration data. I'd like to be able to manipulate the write protect bits, such that normally everything is protected unless there's a reason to change it. So, for example, if a setting needs to be changed, the user can issue an 'unlock' command which unprotects the configuration area, and it can be locked again next time the unit boots up. Or, when the bootloader is entered, it can unprotect the application code area, but protect the configuration.

I already do this on other platforms and it works well.

However: on the H523 I can manipulate the write protect bits just fine, provided PRODUCT_STATE = 'Open'. If I allow the code to switch to 'Closed', then any subsequent attempts to change the FLASH_WRPSG bits appear to have no effect, and obviously I can't use a debugger to help figure out why.

TrustZone is disabled.

Is it just not possible to change the write protect bits on a 'Closed' device, even from user code? It would seem a shame to have to leave the entire Flash unprotected, but that would be the only solution if changing those bits isn't possible.

 

[Jocelyn RICARD]

Hello Andy,

according to RM0481 Rev4 Table 53: OB modifiable in closed product, the write protection cannot be changed, the write protection cannot be changed in TZ-CLOSED, CLOSED and LOCKED states.

So, your behaviour is correct.

To protect your code from being modified unintentionally, you can use the MPU.

Another way that I didn't test on H5 could be to provide a wrong sequence to FLASH_NSKEYR.

Consequence as stated in RM is "A wrong sequence locks the FLASH_NSCR register until next system reset."

But this will locks all the flash. The change in configuration may be more tricky to implement.

Best regards

Jocelyn

 

[andy]

Thanks for the quick response.

I did see table 53, but also noted that there's no mention of write protection in table 52 either, nor in the list of bits that can (and cannot) be changed in the description (p 276). Was this an intentional omission?

On other platforms (STM32F4 / F7) I've always used write protection as a matter of good practice. Despite all the added complexity in H5xx this feels like a regression.

I think I'd have liked to see, for example, a product state 'legacy' in which the read and write protection features work just as they did in the earlier CPUs. This was simple to develop with, carried minimal risk of permanently bricking chips, and worked very well in my application.

Could you feed this back to the developers please?