STM32H75x - How to erase properly with removal of secure area?

[Pavel A.]

I have some code that removes a "secure area" on STM32H75x by so called "regression" from RDP level 1 to level 0, which causes full erase.

(Actually this code is based on example very kindly provided by ST support) 

void EraseAll(void)
{
 uint32_t flashUserOpt;
 printf("Launching erase all process. Requires RDPL1 already set\n");
 
 __HAL_FLASH_CLEAR_FLAG_BANK1(FLASH_FLAG_ALL_ERRORS_BANK1);
 HAL_FLASH_OB_Unlock();
 
 FLASH->OPTSR_PRG = 0x13BEAAF0; /* RDP level 0 */
 FLASH->PRAR_PRG1 = 0x80000FFF; /* No PCROP */
 FLASH->SCAR_PRG1 = 0x80000FFF; /* No secure area */
 FLASH->WPSN_PRG1 = 0x000000FF; /* No WRP */
 OBLaunchWithCheck();
 HAL_FLASH_OB_Lock();
}
 
void OBLaunchWithCheck(void)
{
 HAL_StatusTypeDef error;
 if ((error=HAL_FLASH_OB_Launch()) != HAL_OK)
 {
 printf("HAL_FLASH_OB_Launch failed. HAL_ERROR: %d Error code : %8.8x ...\r\n", error, pFlash.ErrorCode);
 printf("Flash->SR1: 0x%8.8x\r\n", FLASH->SR1);
 }
}

The erase usually (*) works, but after a power cycle ST-LINK utility cannot access the chip, says "remove protection".

In this state, the option bytes dialog shows SECURITY bit set.

I then clear the SECURITY bit, save option bytes, then ST-LINK utility regains full access to the chip, can read and program etc.

My question is, can this reset of SECURITY bit be skipped?

In the snippet above, line 9, the value written into FLASH_OPTSR_PRG has SECURITY bit (21) set.

Should it be so or it is error?

Already bricked all my stock of cheap H75x boards, waiting for a new order.

So sorry, I cannot try and test it by myself, until more boards arrive.

@Jocelyn RICARD​ 

By the way - my test boards have H750 revision Y. Has anything relevant changed/improved in revision V?

Thanks in advance,

-- Pavel A.

(*) When the board becomes bricked, the ST-LINK utility detects the chip correctly - but cannot read neither flash nor option bytes; then it disconnects and cannot connect again without a power cycle. It looks like secure area and/or RDP1 still are active, but the code in the secure area has been erased (no signs of this code running).

[Jocelyn RICARD]

Hello Pavel,

First, you can remove the security bit during the regression. So, writing 0x139EAAF0 instead of 0x13BEAAF0 will work as expected.

Now, I don't really catch why the security bit is bothering you.

Also, I would suggest used STM32CubeProgrammer instead o STLink Utility.

About the boards you bricked, normally as long as you can attach, the board is not bricked. Again please try using STM32CubeProgrammer. Even better the CLI interface to be able to use the same script all the time of the development.

The main reason for bricking a board that I can see is to power off the device during a regression.

In that case, the regressions starts by erasing the flash and then removes the protections.

If you interrupt the flash mass erase par of the regression, the secure memory is still activated with a flash not containing complete code.

In that case, you have no way to reconnect. I made the experience on my first tests of this feature :)

As the flash erase time on STM32H7 is quite long (around 5 seconds I would say) it is easy to fall in this trap ...

I hope this will help

Best regards

Jocelyn

[Pavel A.]

Thank you Jocelyn for the reply (and for the demo again)

How much time is required for the mass erase, or how we can detect that it has finished?

I am sure that I waited for more than 5 sec. - about 1 minute.

The security bit is not reset by regression (at least on my rev. Y H750) - so I'd like to avoid extra step to reset it via option bytes after the erase.

I need to provide safe instructions for a tech who will do the updates (or myself, year later)

Regards,

-- pa

[Jocelyn RICARD]

Hi Pavel,

The maximum erase time of flash is available in the datasheet.

For H750, as you have only one sector, this is 3,6 sec.

On H753, the mass erase can take up to 10 seconds with typical value at 5 seconds, which is what I observe.

You can check the duration on your board by simply performing the mass erase through STM32CubeProgrammer.

There is not specific notification that this is finished.

Only way I can see to avoid breaking things is to try to attach in hotplug mode to the target after normal delay.

I made my tests on a Rev V board which is the latest version of the chip. Rev Y is the oldest :)

I should get a STM32H753 Rev Y soon, I'll check the behaviour on this one.

I should also get a STM32H750 revV to double check.

Best regards

Jocelyn