2026-03-17 7:46 AM - edited 2026-03-17 8:54 AM
Hi,
I added some follow-up questions to a message but I'm not sure if anyone will notice as I had already clicked "Accepted Solution" :-
https://community.st.com/t5/stm32-mcus-security/stm32h5-simple-security-settings/m-p/885235/thread-id/9530#M9531
Copying the questions regarding setting H5 security to be more like G4 RDP setting.
1) Since the regression to open performs a full chips erase, am I right in thinking that we can use a common and not secure password? i.e. Revealing the password does not allow access to the firmware.
2) Can I perform all of the steps listed, from my bootloader firmware? As far as I can see, the changes to product state just require a write to write to an option byte. I have yet to find the part of the reference manual that describes how to write the password file but looking through the scripts in the git repo mentioned seems to suggest that something is written to "address_password=0x8FFF000". (Just noticed - that address looks like H503 only, and for the H563 it looks like 0x0FFD 0100)
2026-03-18 8:51 AM - edited 2026-03-18 8:51 AM
Hello @JimJW ,
Regression to the OPEN state in STM32 devices performs a full chip erase. This process erases user flash memory, SRAM, option byte keys, and debug authentication provisioned data, such as certificates and authorized actions. After regression, the device is set to the OPEN product state, and all user-stored content and secrets are erased. Revealing the password or using the correct certificate is required to initiate the regression process. However, this action does not grant access to the existing firmware. Instead, it triggers a mass erase, after which the firmware is no longer present on the device.
When the device is regressed to the open state, all firmware and secrets are erased. Revealing the regression password does not provide access to the firmware. Using a common or non-secure password is not recommended, as it can allow unauthorized individuals to erase the device, resulting in denial of service or loss of control. Use a strong, unique password for regression to maintain device security.
You can find instructions on how to configure the password and enable readout protection (RDP) in the following resource:
How to enable RDP-like product state flash protection - STMicroelectronics Community
2026-03-19 2:54 AM
Thanks for confirming that.
Is it correct to say that by having a common public password would make our H5 security basically the same as for the STM32G4 in our system. i.e. Someone with physical access could connect a JTAG port, and erase the chip - a customer could erase their own system but not gain access to the content? That would meet our requirements.
Thanks for the link. That is helpful, but I am trying to make the devices set their own security from firmware.
For the G4, it is just a matter of setting the RDP level and ensuring that the chip is power cycled. This works fine.
For the H5, I have managed to set the product state to Provisioning, from the H5's own firmware. I still need to set the password which I believe is a matter of writing the content of the DA_ConfigWithPassword.obk file to the user byte memory at 0x0FFD 0100. Then I need to set the state to Closed and the device will be debug locked but recoverable with a debugger and the password. Have I understood that correctly?