cancel
Showing results for 
Search instead for 
Did you mean: 

STM32F44 MCU: Read protection flag not removed

Corono
Associate III

Hi

I try to implement the read protection on my STM32F44 board based on this example:

https://community.st.com/t5/stm32-mcus/how-to-change-the-read-out-protection-on-stm32f4/ta-p/49410

In principle, it works, but I have some strange behavior. My code:

if (level == 0x00 || level == 0x01) {

      FLASH_OBProgramInitTypeDef pOBInit = { 0 };
      HAL_FLASHEx_OBGetConfig(&pOBInit);

      pOBInit.Banks = FLASH_BANK_1;
      pOBInit.OptionType = OPTIONBYTE_RDP;

      if (level == 0x00) {
        new_level = OB_RDP_LEVEL_0;
      }
      else {
        new_level = OB_RDP_LEVEL_1;
      }

      if (new_level != pOBInit.RDPLevel) {

        do {
          //Unlock flash
          status = HAL_FLASH_Unlock();

          //Unlock flash option sections
          status = HAL_FLASH_OB_Unlock();

          pOBInit.RDPLevel = new_level;
          status = HAL_FLASHEx_OBProgram(&pOBInit);

          //Triggers a reset
          status = HAL_FLASH_OB_Launch();

          HAL_FLASH_OB_Lock();
          HAL_FLASH_Lock();
          printLogWarning(halToCANxError(status), "Writing flash read protection failed");

          return 0;

        } while (0);

        //Something failed, flash maybe already unlocked
        HAL_FLASH_OB_Lock();
        HAL_FLASH_Lock();
      }

    }

Two points are not working as they should:

  • When I enable the read protection: As far as I understood, HAL_FLASH_OB_Launch() should trigger a reset. This works when I'm using the debugger. Without debugger, the warning message after HAL_FLASH_OB_Launch() is sent, it seems that these lines are executed. But the read protection is enabled afterwards.
  • When I remove the read protection (Level 0): The flash is erased as planned. However, when I try to reprogram the device, there is still a message that the device is read protected. It seems that the flag was not reset correctly.

Any idea what I can do to solve these issues, especially the second?

Thank you.

1 ACCEPTED SOLUTION

Accepted Solutions
STea
ST Employee

Hello @Corono ,

if the reset is done while the flash memory is not fully erased the RDP  level will stay in level one this is explained in the example your trying to execute :

"if you reset the microcontroller before the FLASH memory is fully erased the RDP byte will stay locked at Level 1 and your program will be deleted, so it is very important so stand still while the FLASH is being mass erased."

so make sure you wait the appropriate time which can take upward of 20 Seconds . also don't forget to remove the CN2 connection of the STlink as referred in the example and after that you can check if the RDP level is set by reconnecting the jumpers and connecting via CubeProgrammer to verify .

BR

 

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

View solution in original post

5 REPLIES 5
Corono
Associate III

I solved the second problem. Because the reset didn't work correctly, I added a manual reset (not in the code above). However, it seems that the MCU was reset to early and the flag was not removed properly. If I remove the manual reset, disabling works.

STea
ST Employee

Hello @Corono ,

if the reset is done while the flash memory is not fully erased the RDP  level will stay in level one this is explained in the example your trying to execute :

"if you reset the microcontroller before the FLASH memory is fully erased the RDP byte will stay locked at Level 1 and your program will be deleted, so it is very important so stand still while the FLASH is being mass erased."

so make sure you wait the appropriate time which can take upward of 20 Seconds . also don't forget to remove the CN2 connection of the STlink as referred in the example and after that you can check if the RDP level is set by reconnecting the jumpers and connecting via CubeProgrammer to verify .

BR

 

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
Corono
Associate III

Thank you for your answer. Understood.

For me, the behavior of the function "HAL_FLASH_OB_Launch()" is still a bit strange. What I observed:

  • When the level is changed from 1 to 0, execution of the code stops after HAL_FLASH_OB_Launch() (which makes somehow sense because the memory is going to be deleted)
  • When the level is changed from 0 to 1 and the debugger is connected, execution of the code stops after HAL_FLASH_OB_Launch() (which makes somehow sense because the debugger connection is directly affected by the change)
  • When the level is changed from 0 to 1 (without debugger), execution of the code does NOT stop after HAL_FLASH_OB_Launch()

However, I can handle this in the code and the module is not reset.

Hello @Corono ,

how can you confirm that code execution in not stopped after HAL_FLASH_OB_Launch()  in the level  changed from 0 to 1 (without debugger) case ? this should not be possible because as you said this should trigger the flash erase  process so i want to know how you identified that the code is still working .

BR

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
Corono
Associate III

A change from OB_RDP_LEVEL_1 to OB_RDP_LEVEL_0 triggers the flash erase, not the other way around.

A change from OB_RDP_LEVEL_0 to OB_RDP_LEVEL_1 enables the read protection. In this case (without debugger), there is no restart. I have a log message after HAL_FLASH_OB_Launch() and this message is sent. And the module stays in operation and is responding to commands it wouldn't after a restart.