Flash memory is always erased when I connect STM32CubeProgrammer to STM32H7B3i-dk board

[onio]

Hi,

Not sure what I am doing wrong but when I program my STM32H7B3I-DK board with STM32CubeProgrammer, all seems fine, the application start to run and everything is okay.

The problem occurs when I click the Disconnect button and later then try to Connect at this point what everything I have programmed in the flash memory of device gets erased.

I am running the Secure Boot Secure Firmware Update (SBSFU) example program. Below is an image of my "Option Bytes" I can't see any of the flag to cause this behavior.

[Piranha]

Probably SBSFU sets RDP to level 1, which makes memory unreadable with debugger.

[onio]

When I set the RDP to level 1, the program stop running all together and when I look at the memory window the flash contents is completely erased.

[Piranha]

I didn't say to you to set RDP...

And for unreadable memory software will show some values, but those are fake.

[onio]

Okay I misread what you said about RDP. Yes you are correct when I flash the chip with the SBSFU firmware it sets the RDP to level 1. It also sets PCROP and Write Protection on some sectors

However there is a standalone Loader application that can run independently of the SBSFU firmware, this project does not affect any of security bits I mentioned in paragraph above.

When I flash the device with STM32CubeProgrammer see image below the application starts to run immediately as set and shown in the image highlighted in red.

However when I power cycle then it stops and when I connect to see contents they all show up as 0xFF which means blank.

[Piranha]

The RDP level applies to whole MCU memory, not some sectors or ranges. Apparently the software shows 0xFF for unreadable memory. Your firmware is there, you just cannot read it with external tools - that's the whole purpose of RDP (ReaDout Protection). :)

Not starting is another issue. The "Run after programming" feature probably starts your code directly bypassing the bootloader, but after that normal reset starts bootloader. With SBSFU there are signature involved - that must be valid.

Also, after setting RDP (even if SBSFU does it), the MCU requires not only reset but a power cycle.

[onio]

"Your firmware is there, you just cannot read it with external tools - that's the whole purpose of RDP (ReaDout Protection). =)"

This has not been my observation. What I have found is that when RDP is at level 1. I agree the whole the memory is protected and can not be read but this is indicated with different error message with the following text "Error: Data read failed" and with this message is rendered none of the memory contents are shown as it used a modal message box.

There are 4 projects that part of the STM32CubeExpansion_SBSFU_V2.3.0 namely: -

1. 2_Images_Loader
2. 2_Images_SBSFU
3. 2_Images_SECoreBin
4. 2_Images_UserApp

The 2_Images_Loader and 2_Images_SBSFU are both loaders, 2_Images_SBSFU is the secured loader which enables all the security features and may optionally use the 2_images_Loader or use a built in loader.

Either of these two loaders can be programmed by the STM32CubeProgrammer. When the secured version is programmed. It prompts the user for a reboot to continue. On power cycling of the board the bootloader takes control and can be used to program the users code.

The 2_Images_Loader on the other hand operates very similar to the SBSFU but does not change the security features and does not prompt the user to power cycle the board.

Not starting is another issue. The "Run after programming" feature probably starts your code directly bypassing the bootloader, but after that normal reset starts bootloader. With SBSFU there are signature involved - that must be valid.

It is the bootloader that I am expecting to run on power up which should then prompt me to load my user application. So the bootloader does not run unless I start from the programmer.