STM32H725 unexpected behavior after enabling RDP Level 1

[Zlzz]

Hello,

On an STM32H725, changing RDP from Level 0 to Level 1 causes the firmware to stop running. In my device, the LED and FDCAN stop responding, even without a debugger connected. During debug session, this occurs in “HAL_FLASH_OB_Launch()”, more specifically after “SET_BIT(FLASH->OPTCR, FLASH_OPTCR_OPTSTART);”.  

After a manual power cycle, the firmware runs normally and RDP Level 1 is successfully applied.

Is this expected behavior? Is a reset required after changing RDP from Level 0 to Level 1,

Thanks!

[Zlzz]

To be more precise, this is the code to set RDP to level 1:

  FLASH_OBProgramInitTypeDef OBInit;

  OPENBL_FLASH_OB_Unlock();

    HAL_FLASHEx_OBGetConfig(&OBInit);

    OBInit.OptionType = OPTIONBYTE_RDP;

    OBInit.RDPLevel   = RDPLevel;

    if (HAL_FLASHEx_OBProgram(&OBInit) != HAL_OK)

    {

      OPENBL_FLASH_OB_Lock();

        return ERROR;

    }

    // OPENBL_FLASH_OB_Lock();

    if (HAL_FLASH_OB_Launch() != HAL_OK)

    {

      Error_Handler(); // This is not the cause of problem

      return ERROR;

    }

With debugger, when the execution reaches “ HAL_FLASH_OB_Launch()”, the hardfault VECTTBL happened:

To rule out debugger causing an illegal flash access when rdp = 1, I repeated this execution after removing the debugger physically. After commanding the application to activate rdp = 1, it appears to stop responding. After  power off and on, rdp = 1 is successfully set and the device works normally.

According to the reference manual, a reset is not required. Therefore I would like to confirm if this behavior is expected or not.

[Pavel A.]

>  During debug session, this occurs in “HAL_FLASH_OB_Launch()”, 

Raising RDP level under debugger is controversial operation, because RDP conflicts with debugger access to the protected resources. So this behavior isn’t surprising.  Hope others with more experience with use of RDP can advice about best practices of activating it.

Power cycle is the best, cleanest way.

 

[Hai]

Hello ​@Zlzz 

For STM32H724xx, the RDP L0 → L1 transition is allowed, with no mass erase and no mandatory debugger disconnect.

However, after programming the option-byte, HAL_FLASH_OB_Launch() triggers the option-byte reload so the new RDP level takes effect. During this reload, the device goes through an internal reset/restart sequence, so execution is not expected to continue normally after this call.

So, the behavior you observe is consistent with that mechanism:

• HAL_FLASH_OB_Launch() is reached
• the application appears to stop responding
• after reset/power cycle, the MCU boots normally with RDP L1 applied

For the debugger case, even if L0 → L1 is not defined as a debugger-disconnect transition, transient fault/reset indications such as HardFault/VECTTBL can still be seen while the option-bytes are being reloaded.

For your code, the recommended sequence is:

1. Unlock Flash option-bytes
2. Program OPTIONBYTE_RDP
3. Call HAL_FLASH_OB_Launch()
4. Do not expect code after this point to continue normally
5. Let the device reset
6. If needed, perform a power cycle for the cleanest restart

Our RM0468: https://www.st.com/resource/en/reference_manual/rm0468-stm32h723733-stm32h725735-and-stm32h730-value-line-advanced-armbased-32bit-mcus-stmicroelectronics.pdf