MCU won't restart after setting RDP level 1 at startup on U575

[ste2108]

Hello,

In order to comply in advance with the incoming CRA regulation, we would like to have RDP1 enabled on our U575. In order to do this the fw, in the early stages of the initialization procedure, will have to check if it's in RDP0 by reading the related OBs and, if so, it will set RDP1 using HAL_FLASHEx_OBProgram:

    HAL_FLASH_Unlock();
    HAL_FLASH_OB_Unlock();
    HAL_FLASHEx_OBGetConfig(&OptionsBytesStruct);
    if(OB_RDP_LEVEL_0 == OptionsBytesStruct.RDPLevel)
    {
        OptionsBytesStruct.OptionType = OPTIONBYTE_RDP;
        OptionsBytesStruct.RDPLevel = OB_RDP_LEVEL_1;
        if(HAL_OK == HAL_FLASHEx_OBProgram(&OptionsBytesStruct))
        {  
            HAL_PWR_EnterSTANDBYMode();
            //HAL_FLASH_OB_Launch();
        }
   }

So far so good, but now it's time to make this changes effective. As far as I understand from other tickets and by practically testing on my board,  calling HAL_FLASH_OB_Launch (commented in my code) will enable RDP1 only after a power cycle of the board. I tried to issue a hard reset using the dedicated pin nRST, but nothing happens.
Alternatively it seems that, at least on some MCUs there's the workaround of sending the MCU in standby mode and waking it up with the IWDG. Some colleagues of a different group made the mechanism work this way on a G0

My questions are:

1) Do I understand well that the HAL_FLASH_OB_Launch will always need a manual power cycle in order to apply RDP1, or there is a way to avoid it and use a hard reset instead?
2) In case 1) is true, does the same mechanism (standby + wakeup by IWDG) that works for G0 MCUs apply to U5 MCUs?

3) If 2) is true, can you provide an example of the relevant steps needed in my code? I suspect that a  HAL_PWR_EnterSTANDBYMode call is not enough

4) If 2) is false, is there a way other than a manual power cycle to wake the MCU up after a RDP0 -> RDP1 transition?

Unfortunately we need to frequently update the MCU on-field , which implies regression from RDP1 to 0 (already implemented by sending the UNPROTECT command to the ST bootloader) and upload of the new firmware on the newly-erased flash (again using the ST bootloader, which after regression is ready to receive data through its proprietary protocol). After this last step the fw should wake up, realize it is in RDP0, trigger the transition to RDP1 with the aforementioned code and reset. Finally the new application fw (now in RDP1) should start.
Thank you.

Kind regards,

Stefano 

[KDJEM.1]

Hello @ste2108 ;

I recommend you to look at How to change readout protection (RDP) level without power-on reset (POR) on the STM32L4 and get inspired to check your configuration.

Thank you.

Kaouthar

[ste2108]

Hello Kaouthar,

thank you for your answer, taking inspiration from the L4 example actually did the job (leaving the code for other users, I had to make a minor modification to take into account different HALs on U5. You also need to enable RTC in the ioc if you didn't already):

 

  FLASH_OBProgramInitTypeDef OptionsBytesStruct;
    // Unlock Flash and Option Bytes
    HAL_FLASH_Unlock();
    HAL_FLASH_OB_Unlock();
    HAL_FLASHEx_OBGetConfig(&OptionsBytesStruct);
   
    if(OB_RDP_LEVEL_0 == OptionsBytesStruct.RDPLevel)
    {
        OptionsBytesStruct.OptionType = OPTIONBYTE_RDP;
        OptionsBytesStruct.RDPLevel = OB_RDP_LEVEL_1;
        if(HAL_OK == HAL_FLASHEx_OBProgram(&OptionsBytesStruct))
        {  
            __HAL_RCC_PWR_CLK_ENABLE();
            HAL_RTCEx_DeactivateWakeUpTimer(&hrtc);
            HAL_RTCEx_SetWakeUpTimer_IT(&hrtc, 4096, RTC_WAKEUPCLOCK_RTCCLK_DIV16, 0); // Program the RTC
            __HAL_PWR_CLEAR_FLAG(PWR_WAKEUP_ALL_FLAG);
            HAL_PWR_EnterSTANDBYMode();
        }
    }
    HAL_FLASH_OB_Lock();
    HAL_FLASH_Lock();

At the end of the process I get the micro in a xBB RDP state (see picture). Could you please confirm that this is equivalent to xDC, which is what Cubeprogrammer points out as the correct value? It quacks like RDP1 anyway (flash cannot be read, can be reverted).

Kind regards,

Stefano

[KDJEM.1]

Hello @ste2108 ;

According RM0456:

I reported STM32CubeProgrammer issue internally.

Internal ticket number CDM0062725 (This is an internal tracking number and is not accessible or usable by customers).  

Thank you.

Kaouthar

[ste2108]

Hello @KDJEM.1 ,

Thank you for your answer. I will wait for a feedback from STM32CP's guys before closing the ticket then.

Kind regards,

Stefano